LogoLogo
OS Docs HomeOS NGDOS APIsOS Download ProductsMore than MapsContact Us
  • More than Maps
  • Geographic Data Visualisation
    • Guide to cartography
      • Introduction to cartography
      • Types of maps
      • Symbology
      • Colour
      • Text on maps
      • Generalisation
      • Coordinate reference systems
      • Projections
      • Scale
      • Map legends
      • Map layout
      • Relief representation
      • North arrows
    • Guide to data visualisation
      • Introduction to data visualisation
      • GeoDataViz design principles
      • Types of visualisation
      • Thematic mapping techniques
      • Data visualisation critique
      • Accessible data visualisation
      • Ethical data visualisation
      • Software
      • Data
    • GeoDataViz assets
      • GeoDataViz basemaps
      • Stylesheets
      • GeoDataViz virtual gallery
      • Equal area cartograms
      • How did I make that?
        • Apollo 11 Landing
        • North York Moors National Park, 70 years
        • Snowdonia National Park, 70 years
        • Great Britain's National Parks
        • Great Britain's Islands
        • Great Britain's AONB's and National Scenic Areas
        • Famous shipwrecks of Pembrokeshire
        • Trig pillars today
        • Britain's most complex motorway junctions
      • #30DayMapChallenge
  • Data in Action
    • Examples
  • Demonstrators
    • 🆕Product Viewer
    • Addressing & location demonstrators
      • Address Portfolio overview
      • Which address product should you use?
      • AddressBase
      • AddressBase Core
      • AddressBase Plus
      • AddressBase Premium
      • Address Classifications
      • Addressing Lifecycle
      • OS Emergency Services Gazetteer
      • What are Vertical Streets?
      • Why are there differences in boundaries?
    • Contextual demonstrators
    • Customer best practice
      • Channel Shift
      • Data Management and OS Data Hub
      • End User Licence vs Contractor Licence
      • 🆕 IDs vs Spatial Relationships
      • Why we should capture good quality addresses at source
      • Why we Snap and Trace
    • Network Demonstrators
      • OS Detailed Path Network
      • OS Multi Modal Routing Network
        • OS Multi Modal Routing Network
      • Water Networks overview
      • OS MasterMap Highways Network and OS NGD Speeds
      • OS MasterMap® Highways Network and OS Open Roads™
    • OS MasterMap Generation APIs
      • Using the OS Features API
      • Using the OS Features API Archive
      • Using the OS Downloads API
      • Using OS APIs in ESRI Software
    • 🆕OS NGD (National Geographic Database)
      • OS NGD Address
      • OS NGD Boundaries
      • 🆕OS NGD Buildings
        • 🆕Building and Building Access Feature Types
        • Building Part and Building Line Feature Types
      • 🆕OS NGD Geographical Names
      • OS NGD Land
      • OS NGD Land Cover enhancements
      • 🆕OS NGD Land Use
      • OS NGD Land Use enhancements
      • 🆕OS NGD Structures
        • 🆕OS NGD Structures
        • Field Boundaries
      • 🆕OS NGD Transport Features
      • 🆕OS NGD Transport Network
      • OS NGD Transport RAMI
      • OS NGD Water Features
      • OS NGD Water Network
      • OS NGD API - Features
      • Ordering OS NGD data
      • Change only updates
      • OS NGD Versioning
      • Creating a topographic map from OS NGD Data
      • Analytical styling for OS NGD data
    • OS MasterMap® demonstrators
    • 🆕Product & API Comparisons
      • 🆕Comparison of Water Network Products
  • Tutorials
    • GeoDataViz
      • Thematic Mapping Techniques
      • Downloading and using data from the OS Data Hub
      • How to download and use OS stylesheets
      • How to use the OS Maps API
      • Creating a bespoke style in Maputnik
    • GIS
      • Analysing pavement widths
      • Basic routing with OS Open Data and QGIS
      • Walktime analysis using OS Multi-modal Routing Network and QGIS
      • Creating 3D Symbols for GIS Applications
      • Constructing a Single Line Address using a Geographic Address
      • Creating a Digital Terrain Model (DTM)
      • Visualising a road gradient using a Digital Terrain Model
      • Visualising a road gradient using OSMM Highways
    • 🆕APIs
      • 🆕Using OS APIs with EPC API
      • 🆕OS APIs and ArcGIS
  • Deep Dive
    • Introduction to address matching
    • Guide to routing for the Public Sector
      • Part 1: Guide to routing
      • Part 2: Routing software and data options
      • Part 3: Building a routable network
    • Unlocking the Power of Geospatial Data
    • Using Blender for Geospatial Projects
    • A Guide to Coordinate Systems in Great Britain
      • Myths about coordinate systems
      • The shape of the Earth
      • What is position?
        • Types of coordinates
        • We need a datum
        • Position summary
      • Modern GNSS coordinate systems
        • Realising WGS84 with a TRF
        • The WGS84 broadcast TRF
        • The International Terrestrial Reference Frame (ITRF)
        • The International GNSS Service (IGS)
        • European Terrestrial Reference System 1989 (ETRS89)
      • Ordnance Survey coordinate systems
        • ETRS89 realised through OS Net
        • National Grid and the OSGB36 TRF
        • Ordnance Datum Newlyn
        • The future of British mapping coordinate systems
        • The future of British mapping coordinate systems
      • From one coordinate system to another: geodetic transformations
        • What is a geodetic transformation?
        • Helmert datum transformations
        • National Grid Transformation OSTN15 (ETRS89–OSGB36)
        • National Geoid Model OSGM15 (ETRS89-Orthometric height)
        • ETRS89 to and from ITRS
        • Approximate WGS84 to OSGB36/ODN transformation
        • Transformation between OS Net v2001 and v2009 realisations
      • Transverse Mercator map projections
        • The National Grid reference convention
      • Datum, ellipsoid and projection information
      • Converting between 3D Cartesian and ellipsoidal latitude, longitude and height coordinates
      • Converting between grid eastings and northings and ellipsoidal latitude and longitude
      • Helmert transformation worked example
      • Further information
  • Code
    • Ordnance Survey APIs
    • Mapping
    • Routing with pgRouting
      • Getting started with OS MasterMap Highways and pgRouting
      • Getting started with OS MasterMap Highways Network - Paths and pgRouting
      • Getting started with OS NGD Transport Theme and pgRouting
      • Getting started with OS NGD Transport Path features and pgRouting
  • RESOURCES
    • 🆕Data Visualisation External Resources
Powered by GitBook

Website

  • Ordnance Survey

Data

  • OS Data Hub
On this page
  • Datum definition before the space age
  • Realising the datum definition with a Terrestrial Reference Frame

Was this helpful?

  1. Deep Dive
  2. A Guide to Coordinate Systems in Great Britain
  3. What is position?

We need a datum

We have come some way in answering the question ‘What is position?’ by introducing various types of coordinates: we use one or more of these coordinate types to state the positions of points and features on the surface of the Earth.

No matter what type of coordinates we are using, we will require a suitable origin with respect to which the coordinates are stated. For instance, we cannot use Cartesian coordinates unless we have defined an origin point of the coordinate axes and defined the directions of the axes in relation to the Earth we are measuring. This is an example of a set of conventions necessary to define the spatial relationship of the coordinate system to the Earth. The general name for this concept is the Terrestrial Reference System (TRS) or geodetic datum. Datum is the most familiar term amongst surveyors, and we will use it throughout this booklet. TRS is a more modern term for the same thing.

The term geodetic datum is often misused. Datum refers only to the arbitrarily chosen elements of a coordinate system necessary to define the origin of coordinates – not to any control network based on this.

To use 3-D Cartesian coordinates, a 3-D datum definition is required, in order to set up the three axes, X, Y and Z. The datum definition must somehow state where the origin point of the three axes lies and in what directions the axes point, all in relation to the surface of the Earth. Each point on the Earth will then have a unique set of Cartesian coordinates in the new coordinate system. The datum definition is the link between the ‘abstract’ coordinates and the real physical world.

To use latitude, longitude and ellipsoid height coordinates, we start with the same type of datum used for 3-D Cartesian coordinates. To this, we add a reference ellipsoid centred on the Cartesian origin, the shape and size of which is added to the datum definition. The size is usually defined by stating the distance from the origin to the ellipsoid equator, which is called the semi-major axis a. The shape is defined by any one of several parameters: the semi-minor axis length b (the distance from the origin to the ellipsoid pole), the squared eccentricity e², or the inverse flattening 1/f1/f1/f. Exactly what these parameters represent is not important here. Each conveys the same information: the shape of the chosen reference ellipsoid.

The term geodetic datum is usually taken to mean the ellipsoidal type of datum just described: a set of 3-D Cartesian axes plus an ellipsoid, which allows positions to be equivalently described in 3-D Cartesian coordinates or as latitude, longitude and ellipsoid height. The datum definition consists of eight parameters: the 3-D location of the origin (three parameters), the 3-D orientation of the axes (three parameters), the size of the ellipsoid (one parameter) and the shape of the ellipsoid (one parameter).

There are, however, other types of geodetic datum. For instance, a local datum for orthometric height measurement is very simple: it consists of the stated height of a single fundamental bench mark.

Modern height datums are becoming more and more integrated with ellipsoidal datums through the use of Geoid models. The ideal is a single datum definition for horizontal and vertical measurements

What all datums have in common is that they are specified a priori – they are in essence, arbitrary conventions, although they will be chosen to make things as easy as possible for users and to make sense in the physical world. Because the datum is just a convention, a set of coordinates can in theory be transformed from one datum to another and back again exactly. In practice, this might not be very useful, as we shall see in later pages

Datum definition before the space age

How do we specify the position and orientation of a set of Cartesian axes in relation to the ground, when the origin of the axes, and the surface of the associated ellipsoid, are within the Earth? The way it used to be done before the days of satellite positioning was to use a particular ground mark as the initial point of the coordinate system. This ground mark is assigned coordinates that are essentially arbitrary, but fit for the purpose of the coordinate system.

Also, the direction towards the origin of the Cartesian axes from that point was chosen. This was expressed as the difference between the direction of gravity at that point and the direction towards the origin of the coordinate system. Because that is a three-dimensional direction, three parameters were required to define it. So, we have six conventional parameters of the initial point in all, which correspond to choosing the centre (in three dimensions) and the orientation (in three dimensions) of the Cartesian axes. To enable us to use the latitude, longitude and ellipsoid height coordinate type, we also choose the ellipsoid shape and size, which are a further two parameters.

Once the initial point is assigned arbitrary parameters in this way, we have defined a coordinate system in which all other points on the Earth have unique coordinates – we just need a way to measure them! We will look at the principles of doing this in the next section.

Although it is a good example of defining a datum, these days, a single initial point would never be used for this purpose. Instead, we define the datum ‘implicitly’ by applying certain conditions to the computed coordinates of a whole set of points, no one of which has special importance. This method has become common in global GNSS coordinate systems since the 1980s. Avoiding reliance on a single point gives practical robustness to the datum definition and makes error analysis more straightforward.

Realising the datum definition with a Terrestrial Reference Frame

With our datum definition we have located the origin, axes and ellipsoid of the coordinate system with respect to the Earth’s surface, on which are the features we want to measure and describe. We now come to the problem of making that coordinate system available for use in practice. If the coordinate system is going to be used consistently over a large area, this is a big task. It involves setting up some infrastructure of points to which users can have access, the coordinates of which are known at the time of measurement. These reference points are typically either on the ground, or on satellites orbiting the Earth. All positioning methods rely on line-of-sight from an observing instrument to reference points of known coordinates. Putting some of the reference points on orbiting satellites has the advantage that any one satellite is visible to a large area of the Earth’s surface at any one time. This is the idea of satellite positioning.

The network of reference points with known coordinates is called the coordinate Terrestrial Reference Frame (TRF), and its purpose is to realise the coordinate system by providing accessible points of known coordinates. Examples of TRFs are the network of Ordnance Survey triangulation pillars seen on hilltops across Britain, and the constellation of 24 GPS satellites operated by the United States Department of Defense. Both these TRFs serve exactly the same purpose: they are highly visible points of known position in particular coordinate systems (in the case of satellites, the points move so the ‘known position’ changes as a function of time). Users can observe these TRF points using a positioning tool (a theodolite or a GNSS receiver in these examples) and hence obtain new positions of previously unknown points in the coordinate system.

A vital conceptual difference between a datum and a TRF is that the former is errorless while the latter is subject to error. A datum might be unsuitable for a certain application, but it cannot contain errors because it is simply a set of conventionally adopted parameters – they are correct by definition! A TRF, on the other hand, involves the physical observation of the coordinates of many points – and wherever physical observations are involved, errors are inevitably introduced. Therefore it is quite wrong to talk of errors in a datum: the errors occur in the realisation of that datum by a TRF to make it accessible to users.

Most land surveyors do not speak of TRFs – instead we often misuse the term ‘datum’ to cover both. This leads to a lot of misunderstandings, especially when comparing the discrepancies between two coordinate systems. To understand the relationship between two coordinate systems properly, we need to understand that the difference in their datums can be given by some exact set of parameters, although we might not know what they are. On the other hand, the difference in their TRFs (which is what we generally really want to know) can only be described in approximate terms, with a statistical accuracy statement attached to the description.

In the next few pages, we look at real geodetic coordinate systems in terms of their datums and TRFs in some detail. These case studies provide some examples to illustrate the concepts introduced here.

PreviousTypes of coordinatesNextPosition summary

Last updated 4 months ago

Was this helpful?