Back

Technical specification National Polygon dataset

Overview

The National Polygon Dataset (NPD) is the published dataset of HM Land Registry (HMLR) Index Polygons for England and Wales.

HMLR registers ownership of land and property in England and Wales. On completion of a registered title HMLR produces a title plan (in most cases), a register and one or more index polygons.

The title plan and register record the general position of the boundaries of a registered title (unless shown as having been determined as an exact boundary).

An index polygon is part of the Index referred to in s68, 2002 Land Registration Act and r10, Land Registration Rules 2003. Its purpose is to provide an index to show the indicative location of a registered title. Index polygons are held in vector format.

The title plan and register share the same ID called the title number. Every registered title has at least one index polygon. An index polygon has a unique Polygon ID (Poly_ID). The relationship between the registered title and index polygon(s) is managed through the title number.

HMLR index polygons are mapped against Ordnance Survey (OS) large scale data, MasterMap. Index polygons will follow features in MasterMap where those features relate to the ownership boundary. Ownership boundaries do not always follow features mapped in MasterMap. A feature could be for example, a road, path or hedge.

Specification scope

Inclusions and exclusions

The National Polygon Dataset is a sub-set of the Land Register containing all registered titles relating to land or property.

Relationship to other HM Land Registry data products

The National Polygon Dataset is closely linked to Title Descriptor and UPRN datasets. They have been separated so that the datasets are smaller and easier to manage and maintain.

Index polygons have a title number so that they can be linked to the Title Descriptor and UPRN datasets.

INSPIRE Index Polygons are a sub-set of the National Polygon Dataset. These polygons have a simpler attributes which give the identifier, the create date and the polygon last updated date.

The title number is a unique identifier that can be linked to other HM Land Registry data.

Data content and structure

Table 1 - National polygon dataset: Class diagram

Class diagram of the dataset which describes the content and structure
National Polygon
Shape
Poly_ID
Title_No
INSERT
UPDATE
Vers_No
Rec_Status

Table 2 - National polygon dataset: Table structure

Description of the data fields in the dataset
Field name Data type Mandatory Description
Shape Geometry Yes Geometry of the Index Polygon must be a single area
Poly_ID Number Yes Unique polygon reference.
Identifier is unique to spatial object and managed through lifecycle rules for the dataset
Title_No Character Yes Unique number which identifies a registered title to land
INSERT Date Yes Date on which the polygon in the title was initially created on the index map
UPDATE Date Yes Date on which all or part of the title was last updated
Vers_No Number Yes Version of Poly_ID
Rec_Status Character Yes Identifier to describe status of the polygon. Added (A), Changed (C), Deleted (D)

Data quality

Overlaps, gaps, slivers and underlaps all exist in the dataset. Many are genuine and are acceptable but there are some that exist which should not.

Some inconsistencies in the dataset include:

  • small gaps and overlaps
  • technical overlapping polygons - These are polygons where small overlaps exist due to mapping inconsistencies. They do not describe a real conflict of registered titles.
  • actual overlaps – These are where two or more registered titles include the same land or property and will be resolved upon application.

The data also contains data types that facilitate the process of Land Registration and are a managed part of the data model. These feature types are explained further on in this document.

Topology is defined as how point, line and polygon features share coincident geometry, in the context of index polygons topology describes how polygons relate to and interact with each other.

We try to make sure that our public data is accurate, but we cannot guarantee that it is free from errors or fit for your purpose or use.

Table 3 - Types of polygon overlaps and underlaps

Description of the types of polygon overlaps and underlaps in the dataset
Type Description
Acceptable overlapping polygons HMLR deals with registrations at different floor levels, strata, different tenures and classes of title; it is therefore acceptable for polygons to overlap. When overlapping polygons of this nature are referred to the caseworker they classify it accordingly and allow it to remain in the dataset
Illegal overlapping polygons These are overlaps that arise that shouldn’t be in our data. On system referral of an index polygon overlap, the caseworker investigates and may resolve index polygon overlaps. However, where title extents genuinely overlap, HMLR has limited powers to amend registered extents so no action is taken until an application to amend/rectify is received
Minor overlapping polygons Overlaps <0.5m2 are not referred to caseworkers for remedial action, this is because they are insignificant and are too small to satisfactorily resolve with the mapping toolset in the mapping system
Gaps, slivers and underlaps between polygons As part of the registration process consideration is given to adjoining registrations. Where titles are intended to adjoin, practice advices that minor index polygon discrepancies should be resolved. It is right that some registered titles do not adjoin and in that instance the index polygons will not either

Data capture information

An index polygon is a representation of the title extent. HM Land Registry practice allows for an index polygon extent to be the same size, larger or smaller than the extent shown on the title plan. This means they should not be relied on to show the exact extent of registered titles. The dataset includes polygons based on former practices and does contain inconsistencies.

Index polygons were manually captured on OS county series sheets, national grid sheets and parcels books.

In February 2004 HM Land Registry completed a project to convert 19 million index polygons from paper format to vectorised polygons. These polygons were mapped against OS Land-Line.

With so many polygons to vectorise within a finite time frame, HMLR was pragmatic in achieving an effective and efficient capture at that time. This meant that we introduced temporary practice, index polygons were completed pictorially and title plans were seldom used to validate an indexed extent.

Index polygons affected by the OS’ Positional Accuracy Programme (PAI) were subsequently amended. HM Land Registry’s PAI program ran from 2005 to 2008. Many were moved in sympathy with the OS mapping. This was done through an automated process. Those that did not meet certain criteria were referred for manual investigation whereby index polygons were manually compared with the title plan.

Around 2009 HMLR embarked on a quality initiative called the Quality Improvement Flowline (QIF); almost 14 million index polygons went through this process. Some minor overlaps were resolved and extent matching was done automatically, each index polygon was reconciled with the title plan. By this time HM Land Registry was taking OS MasterMap (OSMM), the new large-scale map product from Ordnance Survey which replaced LandLine.

HMLR receives a daily change only update (COU) of OSMM but this is used for the creation of new Index Polygons and Title Plans, rather than to review or update current registrations. Index Polygons will be updated when there is appropriate activity on a title, or an adjoining title demands a change.

Large scale OS map products (OS LandLine and OSMM) capture features at various scales 1:1,250 for urban areas, 1:2,500 for semi urban and rural areas and 1:10,000 for mountain and moorland areas.

All HMLR data including index polygons are captured to British National Grid.

Table 4: National polygons dataset: Feature types

Description of the feature types included
No Type Description
1 Indicative Extent Current practice The index polygon is a good representation of, if not identical to the title plan. This is the most common feature in the dataset.
2 Footprint Current practice It is difficult to interpret an index map where there are multiple titles in one building. HMLR captures footprint index polygons to deal with this. Footprint indexing involves the capture of an area larger than the title extent. Normally the footprint will be captured to the defined boundaries of a building shown on OSMM. The index polygon is captured to the smallest footprint that fully accommodates the title extent. Where the registered title comprises land that falls outside the building footprint e.g. garden ground / parking space this should be shown as a separate polygon(s) with an indicative extent. Commonly seen in floor level registrations, also bin stores, advertising hoardings and solar panels.
3 Artificial Footprint Current practice Where a large number of floor level registrations affect an unusually large defined area on the OSMM (typically a shopping mall or similar development) indexing to the footprint of the whole development makes interrogating the index map less effective. HMLRs mapping system struggles to deal with a huge amount of multiple layered polygons. In such circumstances HMLR may be divide the area into smaller artificial footprint areas within the building footprint. If it is difficult to clearly show small registrations that are not defined on the OSMM. We may capture a larger artificial footprint to include all the small areas. Artificial footprint is commonly seen in shopping malls, small plot schemes and bin stores.
4 Exaggerated Extent Current practice All index polygons should have a width of at least 1m so that small areas of land that are undefined on OSMM can be identified. Where a narrow strip of registered land adjoins other registered land, the adjoining index polygon will be reduced in size to allow for the strip to be shown with a 1m width. Exaggerated extents are commonly seen with ransom strips and pipelines of less than 1m.
5 Gridding Former practice Index polygons were indexed on the appropriate national grid 1km or quadrant sheet. The vectorisation programme was managed by national grid reference. Therefore, where index polygons fell across sheets this was replicated. This means that index polygons stopped at sheet joins. The impact of this is that fields, houses, roads for example are sometimes split into parts each with its own polygon ID (PID).
6 Coexstensive leasehold Former practice Some leasehold index polygons were captured to the extent of the freehold index polygon, even though the extent was lesser than the freehold. HMLR changed this practice because it caused difficulties interrogating the index map to determine title numbers for parts of garden ground and parking spaces.

Data maintenance

HM Land Registry does not routinely update title plans or index polygons. We may do if:

  • we get a query from a customer
  • we notice an adjoining registration is incorrect during another application
  • we notice that a polygon is incorrect
  • a piece of land is sold and needs to be removed from a title and index polygon

Overnight, index polygons created/updated/deleted in the production environment that day are uploaded to the publication environment as ESRI shapefiles (PDF). Through this process the polygons undergo simple validation; checking for zero co-ordinate polygons, zero area polygons and duplicate co-ordinate points within polygons. Many of the self-intersections are cleaned for the publication environment and polygons with zero areas and those with an area below 0.1m2 are removed from it.

An index polygon may go through several changes but the COU delivery will only contain the latest version. HMLR does not retain the previous versions of it.

NPD will be published and then updated monthly.

Data product delivery

Access to the dataset

There is a charge for the dataset and you’ll have to sign a licence.

You'll be able to access the data after you've:

Granting access

The files are updated and available from the 2nd working day of each month.

You’ll have access to the full dataset, the change only updates and the validation files.

File structure

The dataset is provided as a CSV file. The data in each file will:

  • use a comma to separate each field: ',' (ASCII 44)
  • enclose all fields within double quotes: "" (ASCII 34)
  • send blank fields without a character between double quotes: ""
  • have a date format of DD-MM-YYYY. For example, 14 December 2013 will be shown as 14-12-2013
  • use UTF-8 encoding (the way characters are coded for websites)
  • have line separation removed
  • have the column heading name as the first row

File name

The file names will be structured as follows:

  • Full file - This has been split into several files which have a 2GB limit:
  • LR_POLY_FULL_<3 character month>_<number of file>
  • Example file name structure for April 2020: LR_POLY_FULL_APR_1
  • Change Only Update file: LR_POLY_COU_<DD_MMM_YYYY>
  • Example file name structure for April 2020: LR_POLY_COU_02_APR_2020
  • Validation file: LR_POLY_VALI_<3 character month>
  • Example file name structure for April 2020: LR_POLY_VALI_APR

Contact information

If you have any feedback or questions about this data, contact us via:

Telephone

  • Telephone: 0300 006 0478
  • Monday to Friday, 9am to 5pm

Find out about call charges

Email