OS Pillar Trigpoint Import

OS Pillar Trigpoint Import is an import of a subset of the Ordnace Survey (OS) triangulation station dataset. The original data is supplied as a CSV file covering Great Britain. The import focusses on all the (valid, non-destroyed) pillars in the OS dataset that are currently not in the OSM dataset.

Goals

Currently OSM has upto 1/3rd of the UK pillars present as nodes, but in reality this appears to be significantly less, as the nodes under the grouping man_made=survey_point are myriad and inconsistent.

The goal is to take the best available open data source (from the OS), and import as many pillars into OSM that is practicable whilst handling any conflation.

Schedule

The first evaluation happened back in 2016.

A new evaluation was started around the end of May 2026.

The topic was raised on the Talk-GB mailing list 2026-06-09.

Discussion is on-going on the UK forum. Ideally the import will conclude during 2026.

Import Data

Background

The following data sources are used:

Ordnance Survey triangulation stations CSV: https://www.ordnancesurvey.co.uk/geodesy-positioning/legacy-data/trig-search

Data license: https://www.nationalarchives.gov.uk/information-management/re-using-public-sector-information/uk-government-licensing-framework/open-government-licence/

Type of license: OGL-UK-3.0 (detailed on the OS page under the Read more click-to-expand section)

Link to permission From 2016: https://www.nationalarchives.gov.uk/information-management/re-using-public-sector-information/uk-government-licensing-framework/open-government-licence/

OSM attribution (if required): From the OGL license page:

The OGL requires you to attribute the information provider and source of the information. This is already handled on the generic OSM copyright page

ODbL Compliance verified: Confirmed with OSM LWG via email on 2026-07-13, Ticket#2026062410000538

Ordnance Survey benchmarks CSV: https://www.ordnancesurvey.co.uk/geodesy-positioning/legacy-data/benchmark-search

Data license: https://www.nationalarchives.gov.uk/doc/open-government-licence/version/3/

Type of license: OGL-UK-3.0 (detailed on the OS page under the Read more click-to-expand section)

Link to permission: Implicit from OGL-UK-3.0

OSM attribution: Yes

The OGL requires you to attribute the information provider and source of the information. This is already handled on the generic OSM copyright page

ODbL Compliance verified: Confirmed with OSM LWG via email on 2026-07-13, Ticket#2026062410000538

OSM Data Files

OSM datafiles, in the form of OSC XML change files, are provided on the github repository.

Import Type

The primary import of all missing pillars that have no conflation should be a one time import. The UK trigpoints are no longer built or maintained, and the databases being used are no longer maintained. Thus the source data should not change. Apart from any pillars that are destroyed in the future, the data should be static.

This import is planned to be performed either using JOSM or the bulk_upload/upload Python scripts.

Additionally, a Leaflet based slippy map is provided showing the current state of all OSM pillar points and related OSM man_made=survey_point nodes for aid in pre/post import review, tracking progress and viewing and comparing data for any hand applied fixes.

Data Preparation

The Data is loaded, parsed and processed with R. The code is available on github, along with details of the algorithms used.

The OS triangulation data coordinates are supplied in OSGB36 Northing/Easting format with ODN heights. The R sf library, and the underlying PROJ library, are used to convert the OSGB36+ODN coordinates into ETRS89+EGM96 utilising OSTN15 NTv2 data.

The OS benchmark data coordinates are supplied in British National Grid format, including grid squares. The R osbng library supplied by the OS along with sf/PROJ is used to convert these to ETRS89.

The OSM man_made=survey_point nodes are extracted from geofabrik data using osmosis.

All further workings are done in ETRS89.

The code uses the OS triangulation station data to collate and locate the pillars. It then correlates the OS benchmark data against those pillars to extract flush bracket numbers associated with those pillars. Sadly the benchmark flush bracket data is both inconsistent and incomplete, but does provide a large quantity of useful additional data (flush bracket numbers) that can be added as ref tags to the OSM nodes.

Data Reduction & Simplification

The resulting pillar data is then correlated against the UK OSM data for type man_made=survey_point, for any OSM point that is either marked as a pillar or of unknown type (that is, anything explicitly not a pillar is removed from the processing).

Only OS pillars that do not have an OSM survey_point node within 150m are thus classified as a 'new' trigpoint, and will be considered part of the automated bulk import.

N.B.: Other resulting categories of node the code generates OSC files for, but are not intended to be part of this import are:

'good' for pillars that already align well with OSM nodes, and thus need no further work.

If we consider all tags we would like applied to nodes, there are presently no 'good' nodes in OSM, as we are introducing some new tags - but there are approx. 307 nodes that are 'very close'.

'review' for any pillars that look similar to an OSM node, but are inconsistent, and thus could do with human review

'edit' for any OSM nodes that could potentially be automatically updated to align their positions and tags with the OS data - but are not planned as part of this import.

Positional Accuracy

The positional accuracy of the OS pillar trigpoints should be very good. The original OS data page states:

The archive coordinates supplied for these triangulation stations have not been realised via ETRS89 and OSTN15. They are the original archive coordinates and can therefore no longer be considered as true OSGB36 National Grid Coordinates of the station. It is expected that agreement between ETRS89/OSTN15 derived coordinates and the original archive coordinates of triangulation stations (down to third order) will be at the 0.10 metre root mean square (r.m.s) level.

We then use Proj, from within the R sf library to do the transform to ETRS89 and force it to use the best transform it can (using the OS supplied OSTN15 NTv2 dataset). This what the conversion log output says:

Transforming 7405 (OSGB36+ODN) -> 4937 (ETRS89) with accuracy 0.038m

My interpretation of that is <=0.10m accuracy to true position?

Tagging Plans

All new nodes will be created as man_made=survey_point nodes, placed at the coordinates derived from the OS triangulation data Easting/Northing. The following tags will be included in all new nodes:

Source DB	Source Attribute	Tag	Notes
OS trig archive	Trig Name	name	The common name
OS trig archive	New Name	ref:GB:complete_trig_archive	The unique OS new style identifier
OS trig archive	TYPE OF MARK	survey_point:structure	pillar in this instance
OS trig archive	HEIGHT	ele	ODN elevation in metres
-	-	note	Please do not move this node without first reading https://wiki.openstreetmap.org/wiki/OS_pillar_trigpoint_import
-	-	survey_point:datum_aligned	yes
-	-	survey_point:purpose	both
-	-	operator	Ordnance Survey
-	-	operator:wikidata	Q548721

Note: the ref:GB:complete_trig_archive is in effect a new tag for man_made=survey_point / survey_point:structure=pillar nodes. Not only will it hold the unique OS triangulation data 'New Name' for the node, but can also later be used for verification and conflation to determine which OSM nodes have already been imported, ammended or reviewed, and which have not.

Note: the note tag is inspired by the similar trigpoint import for France. If we presume that the OS data is as accurate as any other data we will get for a trigpoint position, then requesting that this data is not updated in the future (without good cause and justification) does not feel overly onerous.

The following tags are optional, depending on the completeness of the data available for each node.

Source DB	Source Attribute	Tag	Notes
OS Benchmark	DESCRIPTION	ref	The flush bracket number derived from the benchmark data, if available

Many existing OSM nodes already contain this ref containing flush bracket information.

The following is an example of the generated OSC XML for a new node:

 
  <create>
    <node id="-15" changeset="1" version="1" lat="57.5390427" lon="-4.5317227">
      <!--OS Name Achnasoul OS New Name NH54T001-->
      <!--OS node Slippy URL: https://grahamwhaley.github.io/OSM_UK_trigpoints/web/index.html#57.5390427,-4.5317227,15z-->
      <tag k="man_made" v="survey_point"/>
      <tag k="name" v="Achnasoul"/>
      <!--ele tag is in ODN-->
      <tag k="ele" v="71.816"/>
      <tag k="survey_point:structure" v="pillar"/>
      <tag k="survey_point:datum_aligned" v="yes"/>
      <tag k="survey_point:purpose" v="both"/>
      <!--Nearest FB is at 4.67 m-->
      <tag k="ref" v="S8049"/>
      <!-- Distance to nearest OSM node 8815604465 is 4270.67 m-->
      <tag k="operator" v="Ordnance Survey"/>
      <tag k="operator:wikidata" v="Q548721"/>
      <tag k="ref:GB:complete_trig_archive" v="NH54T001"/>
      <tag k="note" v="Please do not move this node without first reading https://wiki.openstreetmap.org/wiki/OS_Pillar_Trigpoint_Import"/>
    </node>
  </create>

Changeset Tags

The following tags will be applied to the changeset:

Key	Value
comment	Add all missing UK triangulation pillars from the OS dataset
created_by	https://github.com/grahamwhaley/OSM_UK_trigpoints
import	yes
source:url	https://www.ordnancesurvey.co.uk/geodesy-positioning/legacy-data/trig-search
source:date	2026-05-20 (to be set at actual import date)
import:page	https://wiki.openstreetmap.org/wiki/OS_pillar_trigpoint_import
source:license	OGL-UK-3.0

Data Transformation

All processing is done with R. The code can be found on github, where a fuller description of the data flow and processing can also be found.

The OS data is imported from CSV files and converted from the UK grid co-ordinates to ETRS89. It is then filtered and correlated and sets of nodes for import or potential conflation or human review are generated as OSC XML change files. Only new nodes will be considered for this import.

Data Transformation Results

OSC XML files are posted on the github repository.

Data Merge Workflow

The plan is to merge the data with OSM via JOSM or the Python upload scripts. Before the full import it is planned to:

Do dry runs on the dev server API

Do one or more initial small imports to verify correct results and reduce any necessary rollback, for instance we could start by importing for small UK counties (Isle of Wight, Rutland etc.).

Team Approach

Presently this is a solo effort, but input, review and help is more than welcome.

Workflow

The workflow will be:

Perform test imports of small datasets (subsets) onto the dev server.
- Review
Inform community of pending import
Perform a small import to the main server.
- Review
Enable 'full goodness' checking in the tools, now we have some 'good' nodes to reference.
Re-generate the OSC files to take into account the new 'good' nodes and review for correctness
- Review performed by manual inspection of the XML and visual inspection both on the slippy map and by loading the OSC files into JOSM.
Update github and OSM wiki page.
Inform community of import
Perform test import of remaining nodes to dev server
Perform import of remaining nodes to main server.
- Review
- Re-process fresh OSM data and check for correct import and expected changes in OSC files and slippy map.
Update github and OSM wiki page.

If any revert is necessary then help will be asked for. Given the imports should only be making new nodes and all those nodes should be identifiable from the ref:GB:complete_trig_archive tag. There should not be any major challenges reverting the changeset using scripts such as revert.pl for instance.

The current analysis of the data shows the import will add something in the region of 4437 new nodes.

Conflation

This import is intended to avoid all conflation with exsting nodes. The code tries to identify OS pillars that have no current representation in OSM.

The code does generate a list of edit nodes which are suitable candidates for automatic import with conflation (merging), but this import plan does not cover those nodes. If this import is successful then a second import plan may be constructed to cover the mergeable nodes - presently around 772 nodes.

There are around 307 nearly 'good' nodes, and a hand driven effort may be undertaken to bring those nodes into line with the imported nodes after the import has taken place.

QA

Notification of this project was discussed on the talk-GB mailing list. Further notifications and discussion will happen via that list.

Discussion

The preliminary post to the community forum was sent on 2026-06-09 and can be found here. Further discussion has been continuing on the UK forum.

OS Pillar Trigpoint Import

Contents

Goals

Schedule

Import Data

Background

OSM Data Files

Import Type

Data Preparation

Data Reduction & Simplification

Positional Accuracy

Tagging Plans

Changeset Tags

Data Transformation

Data Transformation Results

Data Merge Workflow

Team Approach

Workflow

Conflation

QA

Discussion

Navigation menu

OS Pillar Trigpoint Import

Goals

Schedule

Import Data

Background

OSM Data Files

Import Type

Data Preparation

Data Reduction & Simplification

Positional Accuracy

Tagging Plans

Changeset Tags

Data Transformation

Data Transformation Results

Data Merge Workflow

Team Approach

Workflow

Conflation

QA

Discussion

Navigation menu

Search