1 of 100

OS Downloads

OS Download Products' Documentation

Explore documentation and guides for OS Premium and OpenData Download products, such as AddressBase Premium, OS MasterMap Topography Layer, Boundary-Line and OS Open Zoomstack.

What's available on this site?

On the left-hand-side menu, under each product listing, we've arranged the documents from high-level Overview to low-level Technical Specification. A Getting Started Guide and Release Notes are available for most products. We've also added links to any additional files (for example, CSV header files, stylesheets and XML schemas) available for some products but held on separate OS sites on product-specific 'Downloads' pages.

There are two types of Download data product: OS Premium and OS OpenData.

What are OS Premium Download data products?

Our Premium Download data products work in a range of software, including ESRI ArcGIS, QGIS, Mapbox, Cadcorp SIS, MapInfo, Tableau, Kepler.gl and many more.

What are OS OpenData Download products?

OS OpenData Download products are free to use by anyone for any purpose – including for services from which you make a profit.

Download product portfolios

Addressing and Location

Addressing and Location Portfolio Information

This page provides an overview of the OS downloadable products in the Addressing and Location Portfolio.

Addressing and location products

Addressing and location products provide authoritative and accurate address, property and land data, with comprehensive location-based directories for users to draw from. The following downloadable products are available within the Addressing and Location Portfolio:

AddressBase Fundamentals

The following AddressBase Fundamentals pages provide an overview of the 'family' of AddressBase products. They cover key elements of design for AddressBase products, including data formats, classification scheme, product supply, coordinate reference systems, currency, precision, and data sources, amongst other topics.

These pages should be used in conjunction with the detailed technical specifications for each product (which can be found under the top-level product page for each individual product from the left-hand-side menu).

Release Notes

Release notes listed here provide information about the current release of the AddressBase 'family' of products and the previous nine releases.

The 'AddressBase Products' release notes include information on the AddressBase, AddressBase Plus and AddressBase Premium products.
The 'AddressBase Islands' release notes include information on the AddressBase Plus Islands and AddressBase Premium Islands products.

Epoch 118

This release note provides information about the May 2025 (Epoch 118) release of AddressBase products.

This release note provides information about the May 2025 (Epoch 118) release of AddressBase Islands products.

Epoch 117

This release note provides information about the March 2025 (Epoch 117) release of AddressBase products.

This release note provides information about the March 2025 (Epoch 117) release of AddressBase Islands products.

Epoch 116

This release note provides information about the February 2025 (Epoch 116) release of AddressBase products.

This release note provides information about the February 2025 (Epoch 116) release of AddressBase Islands products.

Epoch 115

This release note provides information about the December 2024 (Epoch 115) release of AddressBase products.

This release note provides information about the December 2024 (Epoch 115) release of AddressBase Islands products.

Epoch 114

This release note provides information about the November 2024 (Epoch 114) release of AddressBase products.

This release note provides information about the November 2024 (Epoch 114) release of AddressBase Islands products.

Epoch 113

This release note provides information about the September 2024 (Epoch 113) release of AddressBase products.

This release note provides information about the September 2024 (Epoch 113) release of AddressBase Islands products.

Epoch 112

This release note provides information about the August 2024 (Epoch 112) release of AddressBase products.

This release note provides information about the August 2024 (Epoch 112) release of AddressBase Islands products.

Epoch 111

This release note provides information about the June 2024 (Epoch 111) release of AddressBase products.

This release note provides information about the June 2024 (Epoch 111) release of AddressBase Islands products.

Epoch 110

This release note provides information about the May 2024 (Epoch 110) release of AddressBase products.

This release note provides information about the May 2024 (Epoch 110) release of AddressBase Islands products.

Epoch 109

This release note provides information about the April 2024 (Epoch 109) release of AddressBase products.

This release note provides information about the April 2024 (Epoch 109) release of AddressBase Islands products.

AddressBase Products May 2025 – Epoch 118

This release note provides information about the May 2025 (Epoch 118) release of the AddressBase products. These products were released to customers on 01 May 2025.

Object Without Postal Address (OWPA) enhancement in Epoch 118 for AddressBase Premium and AddressBase Plus

There is a small uplift in this release of both AddressBase Premium and AddressBase Plus due to an improvement in the Object Without Postal Address (OWPA) features contained within these two products. As a result of this uplift, COU counts are around 30% larger, in comparison to the 3 previous releases. This may result in slower processing times.

Record counts

Product

Full Supply Record Count

Change-Only Update Record Count

OS Open UPRN

41 196 104

N/A

AddressBase

30 705 430

152 191

AddressBase Plus

38 390 448

1 085 737

AddressBase Premium

See rows below

Street

1 515 628

4 732

Street Descriptor

1 639 498

3 233

BLPU

41 196 104

790 039

Classification

45 017 696

446 122

LPI

46 450 006

620 587

Organisation

1 398 046

19 314

Delivery Point Address

30 816 296

64 760

Application Cross Ref.

199 441 353

1 235 928

Successor

The Full Supply record counts are based on a Managed Great Britain Set (MGBS). If you have ordered your national coverage via the online ordering system using a polygon outline, then your counts may differ.
Please note that Change-Only Updates (COUs) are not available for the OS Open UPRN product.

Product supply comparison

There is a difference in product counts between taking a national Managed Great Britain Set (MGBS) and a national Area of Interest (AOI). This is because the two supplies use different selection criteria. The differences are shown in the following table, allowing for you to validate your data holdings once you have loaded the latest release of AddressBase data.

The national AOI refers to the pre-selection GB polygon from our download store. Therefore, if you have drawn your own AOI, the count will vary.

If you are unsure of your supply type, please check this with your OS Relationship Manager.

Product

MGBS Full Count

National AOI Full Count

Difference

AddressBase

30 705 430

AddressBase Plus

38 390 448

38 390 426

AddressBase Premium

See rows below

Street

1 515 628

1 515 625

Street Descriptor

1 639 498

1 639 495

BLPU

41 196 104

41 196 078

Classification

45 017 696

45 017 670

LPI

46 450 006

46 449 979

Organisation

1 398 046

1 398 044

Delivery Point Address

30 816 296

Application Cross Ref.

199 441 353

199 441 327

Successor

Changed records

If you receive a Change-Only Update (COU) supply for your AddressBase product, you will receive Insert, Update and Delete records within the supplied file. The following tables detail the numbers of these records which can be expected in an MGBS supply, and also how many tiles are affected if you take your supply as Changed Chunks.

AddressBase

Change Type

Count

Inserts

39 607

Updates

103 385

Deletes

9 199

COU Populated Tile Count

5 450

AddressBase Plus

Change Type

Count

Inserts

146 606

Updates

896 728

Deletes

42 403

COU Populated Tile Count

8 520

AddressBase Premium

AddressBase Premium Table

Inserts

Updates

Deletes

Street

1 524

3 177

Street Descriptor

1 572

1 627

BLPU

146 717

640 377

2 945

Classification

172 147

242 226

31 749

LPI

168 697

448 093

3 797

Organisation

5 785

5 762

7 767

Delivery Point Address

40 444

14 910

9 406

Application Cross Ref.

564 892

636 931

34 105

Source data currency

The following information relates to the currency of the source data used in the creation of Epoch 118:

Data Source

Date

Royal Mail PAF

27 March 2025

National Land and Property Gazetteer

27 March 2025

One Scotland Gazetteer

10 March 2025

VOA Non-Domestic Rates

25 March 2025

VOA Council Tax

25 March 2025

OS MasterMap Topography Layer

27 February 2025

OS MasterMap Highways Network

07 March 2025

Code-Point with Polygons

02 January 2025

Boundary-Line

02 October 2024

Data issues

AddressBase

AddressBase Plus issues

AddressBase Premium

Improvements in Epoch 118

Valuation Office Agency matching

The match rates for Council Tax and Non-Domestic Rates for Epoch Epoch 118 are detailed as follows based on Valuation Office Agency (VOA) records up to 25 March 2025. The match rate is applicable to the AddressBase Premium product.

Data Source

Records Received

% Matched

Council Tax

27 251 204

99.91

Non-Domestic Rates

2 120 750

96.46

Next release

The next release of AddressBase products, Epoch 119, is scheduled for 12 June 2025.

AddressBase Islands May 2025 – Epoch 118

This release note provides information about the May 2025 (Epoch 118) release of the AddressBase Islands products. These products were released to customers on 01 May 2025.

Object Without Postal Address (OWPA) enhancement in Epoch 118 for AddressBase Premium Islands and AddressBase Plus Islands

There is a small uplift in this release of both AddressBase Premium Islands and AddressBase Plus Islands due to an improvement in the Object Without Postal Address (OWPA) features contained within these products. As a result of this uplift, COU counts are around 30% larger, in comparison to the 3 previous releases; this may result in slower processing times.

Record counts

Product

Full Supply Record Count

Change-Only Update Record Count

AddressBase Plus Islands

1 162 955

17 958

AddressBase Premium Islands

See rows below

Street

48 792

321

Street Descriptor

48 792

BLPU

1 241 870

17 908

Classification

1 241 870

3 589

LPI

1 251 678

4 131

Organisation

38 842

254

Delivery Point Address

979 023

14 044

Application Cross Ref.

1 307 510

3 429

Successor

Changed records

If you receive a Change-Only Update (COU) supply for your AddressBase Islands product, you will receive Insert, Update and Delete records within the supplied file. The following tables detail the count of these records.

AddressBase Plus Islands

Change Type

Count

Inserts

8 257

Updates

9 464

Deletes

237

AddressBase Premium Islands

AddressBase Premium Islands Table

Inserts

Updates

Deletes

Street

289

Street Descriptor

BLPU

2 806

14 937

165

Classification

2 806

618

165

LPI

2 825

1 141

165

Organisation

156

Delivery Point Address

13 190

213

641

Application Cross Ref.

2 773

360

296

Successor

Source data currency

The following information relates to the currency of the source data used in the creation of Epoch 118:

Data Source

Date

Pointer (Northern Ireland)

27 March 2025

DigiMap (Channel Islands)

27 March 2025

Isle of Man

27 March 2025

Royal Mail PAF

27 March 2025

Data issues

AddressBase Plus Islands issues

AddressBase Premium Islands issues

Next release

The next release of AddressBase Islands products, Epoch 119, is scheduled for 12 June 2025.

AddressBase Products March 2025 – Epoch 117

This release note provides information about the March 2025 Epoch 117 release of the AddressBase products. These products were released to customers on 20 March 2025.

Record counts

Product

Full Supply Record Count

Change-Only Update Record Count

OS Open UPRN

41 052 332

N/A

AddressBase

30 675 022

138 394

AddressBase Plus

38 286 245

721 346

AddressBase Premium

See rows below

Street

1 514 135

4 127

Street Descriptor

1 637 960

4 765

BLPU

41 052 332

348 127

Classification

44 877 298

198 513

LPI

46 285 106

149 761

Organisation

1 400 028

27 007

Delivery Point Address

30 785 258

57 204

Application Cross Ref.

198 910 566

717 312

Successor

The Full Supply record counts are based on a Managed Great Britain Set (MGBS). If you have ordered your national coverage via the online ordering system using a polygon outline, then your counts may differ.
Please note that Change-Only Updates (COUs) are not available for the OS Open UPRN product.

Product supply comparison

The national AOI refers to the pre-selection GB polygon from our download store. Therefore, if you have drawn your own AOI, the count will vary.

If you are unsure of your supply type, please check this with your OS Relationship Manager.

Product

MGBS Full Count

National AOI Full Count

Difference

AddressBase

30 675 022

AddressBase Plus

38 286 245

38 286 223

AddressBase Premium

See rows below

Street

1 514 135

1 514 132

Street Descriptor

1 637 960

1 637 957

BLPU

41 052 332

41 052 306

Classification

44 877 298

44 877 272

LPI

46 285 106

46 285 079

Organisation

1 400 028

1 400 026

Delivery Point Address

30 785 258

Application Cross Ref.

198 910 566

198 910 540

Successor

Changed records

AddressBase

Change Type

Count

Inserts

32 301

Updates

96 676

Deletes

9 417

COU Populated Tile Count

5 412

AddressBase Plus

Change Type

Count

Inserts

47 638

Updates

659 891

Deletes

13 817

COU Populated Tile Count

7 297

AddressBase Premium

AddressBase Premium Table

Inserts

Updates

Deletes

Street

1 071

3 031

Street Descriptor

1 114

3 616

BLPU

44 401

299 702

4 024

Classification

68 269

102 102

28 142

LPI

59 085

85 866

4 810

Organisation

5 710

8 051

13 246

Delivery Point Address

33 073

14 982

9 149

Application Cross Ref.

191 523

486 447

39 342

Source data currency

The following information relates to the currency of the source data used in the creation of Epoch 117:

Data Source

Date

Royal Mail PAF

13 February 2025

National Land and Property Gazetteer

13 February 2025

One Scotland Gazetteer

27 January 2025

VOA Non-Domestic Rates

10 February 2025

VOA Council Tax

10 February 2025

OS MasterMap Topography Layer

16 January 2025

OS MasterMap Highways Network

06 February 2025

Code-Point with Polygons

02 January 2025

Boundary-Line

02 October 2024

Data issues

AddressBase Plus issues

Affected output formats: CSV and GML

There are 7 966 Unique Property Reference Numbers (UPRNs) which reference a Parent UPRN that cannot be found in the product. This is because the Parent UPRN is either provisional or historic and is not matched to the Royal Mail Postcode Address File (PAF) or Valuation Office Agency (VOA) record, meaning that it is not included in the AddressBase Plus product as per the existing background logic rules.
There are 231 records with a sao_start_no or sao_text that have no Parent UPRN in the product. This is because the Parent UPRN is a historical record which is included as part of the logic for record inclusion in the AddressBase Plus products.

Improvements in Epoch 117

Valuation Office Agency matching

The match rates for Council Tax and Non-Domestic Rates for Epoch 117 are detailed as follows based on Valuation Office Agency (VOA) records up to 10 February 2025. The match rate is applicable to the AddressBase Premium product.

Data Source

Records Received

% Matched

Council Tax

27 247 539

99.9

Non-Domestic Rates

2 120 424

96.48

Tertiary classifications

Work is being undertaken to improve the classifications of records within the AddressBase products. This work has resulted in 69 348 more tertiary classifications present in Epoch 117 compared to Epoch 116. Indeed, 88.6 % of these tertiary classification improvements are against residential codes.

Next release

The next release of AddressBase products, Epoch 118, is scheduled for 01 May 2025.

AddressBase Islands March 2025 – Epoch 117

This release note provides information about the March 2025 Epoch 117 release of the AddressBase Islands products. These products were released to customers on 20 March 2025

Record counts

Product

Full Supply Record Count

Change-Only Update Record Count

AddressBase Plus Islands

1 154 935

3 461

AddressBase Premium Islands

See rows below

Street

48 760

127

Street Descriptor

48 760

BLPU

1 239 229

3 933

Classification

1 239 229

2 023

LPI

1 249 018

2 597

Organisation

38 742

258

Delivery Point Address

966 474

1 129

Application Cross Ref.

1 305 033

1 692

Successor

Changed records

AddressBase Plus Islands

Change Type

Count

Inserts

1 039

Updates

2 234

Deletes

188

AddressBase Premium Islands

AddressBase Premium Islands Table

Inserts

Updates

Deletes

Street

Street Descriptor

BLPU

1 124

2 684

125

Classification

1 124

774

125

LPI

1 193

1 279

125

Organisation

143

Delivery Point Address

654

325

150

Application Cross Ref.

1 114

385

193

Successor

Source data currency

The following information relates to the currency of the source data used in the creation of Epoch 117:

Data Source

Date

Pointer (Northern Ireland)

13 February 2025

DigiMap (Channel Islands)

13 February 2025

Isle of Man

13 February 2025

Royal Mail PAF

13 February 2025

Data issues

AddressBase Plus Islands issues

There are no reported issues in this release of AddressBase Plus Islands.

AddressBase Premium Islands issues

Affected output formats: CSV and GML

Street incorrect coordinates – There are two Streets which have incorrect start or end coordinates of 000000. The unique identifiers can be provided upon request through your OS Relationship Manager.

Next release

The next release of AddressBase Islands products, Epoch 118, is scheduled for 01 May 2025.

AddressBase Products February 2025 – Epoch 116

This release note provides information about the February 2025 (Epoch 116) release of the AddressBase products. These products were released to customers on 06 February 2025.

Known issues will now be displayed on the 'Product Known Data Issues' subpages under each product.

Record counts

Product

Full Supply Record Count

Change-Only Update Record Count

OS Open UPRN

41,011,955

N/A

AddressBase

30,652,138

157,150

AddressBase Plus

38,252,424

582,353

AddressBase Premium

See rows below

Street

1,513,089

5,202

Street Descriptor

1,636,881

2,918

BLPU

41,011,955

320,110

Classification

44,837,171

154,389

LPI

46,230,831

129,683

Organisation

1,407,564

16,239

Delivery Point Address

30,761,334

69,996

Application Cross Ref.

198,758,385

736,674

Successor

The Full Supply record counts are based on a Managed Great Britain Set (MGBS). If you have ordered your national coverage via the online ordering system using a polygon outline, then your counts may differ.
Please note that Change-Only Updates (COUs) are not available for the OS Open UPRN product.

Product supply comparison

The national AOI refers to the pre-selection GB polygon from our download store. Therefore, if you have drawn your own AOI, the count will vary.

If you are unsure of your supply type, please check this with your OS Relationship Manager.

Product

MGBS Full Count

National AOI Full Count

Difference

AddressBase

30,652,138

AddressBase Plus

38,252,424

38,252,403

AddressBase Premium

See rows below

Street

1,513,089

1,513,086

Street Descriptor

1,636,881

1,636,878

BLPU

1,011,955

41,011,930

Classification

44,837,171

44,837,146

LPI

6,230,831

46,230,805

Organisation

407,564

1,407,562

Delivery Point Address

30,761,334

Application Cross Ref.

198,758,385

198,758,360

Successor

Changed records

AddressBase

Change Type

Count

Inserts

43,892

Updates

103,297

Deletes

9,961

COU Populated Tile Count

5,743

AddressBase Plus

Change Type

Count

Inserts

48,887

Updates

521,021

Deletes

12,445

COU Populated Tile Count

6,909

AddressBase Premium

AddressBase Premium Table

Inserts

Updates

Deletes

Street

1,633

3,535

Street Descriptor

1,684

1,194

BLPU

42,757

274,322

3,031

Classification

52,337

82,401

19,651

LPI

57,853

67,612

4,218

Organisation

4,337

4,480

7,422

Delivery Point Address

44,752

15,200

10,044

Application Cross Ref.

192,512

509,368

34,794

Source data currency

The following information relates to the currency of the source data used in the creation of Epoch 116:

Data Source

Date

Royal Mail PAF

02 January 2025

National Land and Property Gazetteer

02 January 2025

One Scotland Gazetteer

09 December 2024

VOA Non-Domestic Rates

23 December 2024

VOA Council Tax

23 December 2024

OS MasterMap Topography Layer

28 November 2024

OS MasterMap Highways Network

05 December 2024

Code-Point with Polygons

02 January 2025

Boundary-Line

02 October 2024

Improvements in Epoch 116

Valuation Office Agency matching

The match rates for Council Tax and Non-Domestic Rates for Epoch 116 are detailed as follows based on Valuation Office Agency (VOA) records up to 23 December 2024. The match rate is applicable to the AddressBase Premium product.

Data Source

Records Received

% Matched

Council Tax

27,227,905

99.92

Non-Domestic Rates

2,120,341

96.44

Tertiary classifications

Work is being undertaken to improve the classifications of records within the AddressBase products. This work has resulted in 49 241 more tertiary classifications present in Epoch 116 compared to Epoch 115. Indeed, 88.69 % of these tertiary classification improvements are against residential codes.

Next release

The next release of AddressBase products, Epoch 117, is scheduled for 20 March 2025.

AddressBase Islands February 2025 – Epoch 116

This release note provides information about the February 2025 (Epoch 116) release of the AddressBase Islands products. These products were released to customers on 06 February 2025.

Known issues will now be displayed on the 'Product Known Data Issues' subpages under each product.

Record counts

Product

Full Supply Record Count

Change-Only Update Record Count

AddressBase Plus Islands

1,154,084

3,135

AddressBase Premium Islands

See rows below

Street

48,727

179

Street Descriptor

48,727

BLPU

1,238,230

4,281

Classification

1,238,230

2,461

LPI

1,247,950

3,075

Organisation

38,827

250

Delivery Point Address

965,970

1,124

Application Cross Ref.

1,304,112

2,138

Successor

Changed records

AddressBase Plus Islands

Change Type

Count

Inserts

1,315

Updates

1,539

Deletes

281

AddressBase Premium Islands

AddressBase Premium Islands Table

Inserts

Updates

Deletes

Street

126

Street Descriptor

BLPU

1,535

2,515

231

Classification

1,535

695

231

LPI

1,544

1,300

231

Organisation

109

Delivery Point Address

886

143

Application Cross Ref.

1,499

297

342

Successor

Source data currency

The following information relates to the currency of the source data used in the creation of Epoch 116:

Data Source

Date

Pointer (Northern Ireland)

02 January 2025

DigiMap (Channel Islands)

02 January 2025

Isle of Man

02 January 2025

Royal Mail PAF

02 January 2025

Next release

The next release of AddressBase Islands products, Epoch 117, is scheduled for 20 March 2025.

AddressBase Products November 2024 – Epoch 114

This release note provides information about the November 2024 (Epoch 114) release of the AddressBase products. These products were released to customers on 07 November 2024.

Update to the location of AddressBase technical documentation and release notes

Over the next few months, the old PDFs containing product technical documentation will be removed from the product pages of the OS website and replaced by links to the refreshed documentation on the new platform.

Record counts

These counts are based on a Managed Great Britain Set (MGBS). If you have ordered your national coverage via the online ordering system using a polygon outline, then your counts may differ.
Change-Only Updates are not available for the OS Open UPRN product.

Product supply comparison

The national AOI refers to the pre-selection GB polygon from our download store. Therefore, if you have drawn your own AOI, the count will vary.

If you are unsure of your supply type, please check this with your OS Relationship Manager.

Changed records

AddressBase

AddressBase Plus

AddressBase Premium

Source data currency

The following information relates to the currency of the source data used in the creation of Epoch 114:

Data issues

AddressBase Plus issues

Affected output formats: CSV and GML

There are 6 038 Unique Property Reference Numbers (UPRNs) which reference a Parent UPRN that cannot be found in the product. This is because the Parent UPRN is either provisional or historic and is not matched to the Royal Mail Postcode Address File (PAF) or Valuation Office Agency (VOA) record, meaning that it is not included in the AddressBase Plus product as per the existing background logic rules.
There are 211 records with a sao_start_no or sao_text that have no Parent UPRN in the product. This is because the Parent UPRN is a historical record which is included as part of the logic for record inclusion in the AddressBase Plus products.

Improvements in Epoch 114

Valuation Office Agency matching

The match rates for Council Tax and Non-Domestic Rates for Epoch 114 are detailed as follows based on Valuation Office Agency (VOA) records up to 01 October 2024. The match rate is applicable to the AddressBase Premium product.

Tertiary classifications

Work is being undertaken to improve the classifications of records within the AddressBase products. This work has resulted in 37 159 more tertiary classifications present in Epoch 114 compared to Epoch 113. Indeed, 88.71% of these tertiary classification improvements are against residential codes.

PAF matching

The following graph shows the number of Postcode Address File (PAF) matched records in AddressBase by epoch:

Next release

The next release of AddressBase products, Epoch 115, is scheduled for 19 December 2024.

AddressBase Islands August 2024 – Epoch 112

This release note provides information about the August 2024 release of the AddressBase Islands products. These products were released to customers on 15 August 2024.

Record Counts

Changed Records

AddressBase Plus Islands

AddressBase Premium Islands

Source Data Currency

The following information relates to the currency of the source data used in the creation of Epoch 112:

Data Issues

AddressBase Plus Islands Issues

There are no reported issues in this release of AddressBase Plus Islands.

AddressBase Premium Islands issues

Affected output formats: CSV and GML

Street incorrect coordinates – There are two Streets which have incorrect start or end coordinates of 000000. The unique identifiers can be provided upon request through your OS Relationship Manager.

Next Release

The next release of AddressBase Islands products, Epoch 113, is scheduled for 26 September 2024.

AddressBase Products December 2024 – Epoch 115

This release note provides information about the December 2024 release of the AddressBase products. These products were released to customers on 19 December 2024.

Record counts

Product

Full Supply Record Count[1]

Change-Only Update Record Count[2]

OS OpenUPRN

40 972 229

N/A

AddressBase

30,618,207

160,698

AddressBase Plus

38,215,982

567,209

AddressBase Premium

See rows below

Street

1,511,490

8,819

Street Descriptor

1,635,237

3,827

BLPU

40,972,229

351,639

Classification

44,804,485

156,612

LPI

46,177,196

155,834

Organisation

1,410,649

24,087

Delivery Point Address

30,726,626

75,116

Application Cross Ref.

198,600,667

735,324

Successor

These counts are based on a Managed Great Britain Set (MGBS). If you have ordered your national coverage via the online ordering system using a polygon outline, then your counts may differ.
Change-Only Updates are not available for the OS Open UPRN product.

Product supply comparison

The national AOI refers to the pre-selection GB polygon from our download store. Therefore, if you have drawn your own AOI, the count will vary.

If you are unsure of your supply type, please check this with your OS Relationship Manager.

Product

MGBS Full Count

National AOI Full Count

Difference

AddressBase

30 618 207

AddressBase Plus

38 215 982

38 215 961

AddressBase Premium

See rows below

Street

1,511,490

1,511,487

Street Descriptor

1,635,237

1,635,234

BLPU

40,972,229

40,972,204

Classification

44,804,485

44,804,460

LPI

46,177,196

46,177,170

Organisation

1,410,649

1,410,647

Delivery Point Address

30,726,626

Application Cross Ref.

198,600,667

198,600,642

Successor

Changed records

If you receive a Change-Only Update (COU) supply for your AddressBase product, you will receive Insert, Update and Delete records within the supplied file. The following tables detail the numbers of these records which can be expected in an MGBS supply,and also how many tiles are affected if you take your supply as Changed Chunks.

AddressBase

Change Type

Count

Inserts

52 317

Updates

92 108

Deletes

16 273

COU Populated Tile Count

5 743

AddressBase Plus

Change Type

Count

Inserts

47 492

Updates

498 918

Deletes

20 799

COU Populated Tile Count

7 094

AddressBase Premium

AddressBase Premium Table

Inserts

Updates

Street

1,175

6,933

711

Street Descriptor

1,225

1,891

711

BLPU

40,941

299,115

11,583

Classification

49,447

77,489

29,676

LPI

54,934

88,243

12,657

Organisation

4,697

4,318

15,072

Delivery Point Address

48,355

15,438

11,323

Application Cross Ref.

203,570

460,627

71,127

Source data currency

The following information relates to the currency of the source data used in the creation of Epoch 115:

Data Source

Date

Royal Mail PAF

14 November 2024

National Land and Property Gazetteer

14 November 2024

One Scotland Gazetteer

28 October 2024

VOA Non-Domestic Rates

11 November 2024

VOA Council Tax

11 November 2024

OS MasterMap Topography Layer

05 November 2024

OS MasterMap Highways Network

07 November 2024

Code-Point with Polygons

01 October 2024

Boundary-Line

02 October 2024

Data issues

AddressBase Plus

Affected output formats: CSV and GML

There are 6 552 Unique Property Reference Numbers (UPRNs) which reference a Parent UPRN that cannot be found in the product. This is because the Parent UPRN is either provisional or historic and is not matched to the Royal Mail Postcode Address File (PAF) or Valuation Office Agency (VOA) record, meaning that it is not included in the AddressBase Plus product as per the existing background logic rules.
There are 219 records with a sao_start_no or sao_text that have no Parent UPRN in the product. This is because the Parent UPRN is a historical record which is included as part of the logic for record inclusion in the AddressBase Plus products.

Improvements in Epoch 115

Valuation Office Agency matching

The match rates for Council Tax and Non-Domestic Rates for Epoch 115 are detailed as follows based on Valuation Office Agency (VOA) records up to 11 November 2024. The match rate is applicable to the AddressBase Premium product.

Data Source

Records Received

% Matched

Council tax

27 201 555

99.92

Non-domestic rates

2 119 490

96.49

Tertiary classifications

Work is being undertaken to improve the classifications of records within the AddressBase products. This work has resulted in 38 207 more tertiary classifications present in Epoch 115 compared to Epoch 114. A total of 88.71% of these tertiary classification improvements are against residential codes.

PAF matching

AddressBase, AddressBase Plus and AddressBase Premium

Increased PAF matches shown in product – 14 102 PAF records had been previously withheld from product due to a processing constraint which omitted UPRNs with multiple candidate PAF matches from showing in product as a one-one match. This was resolved on the 25/10/24.

The following graph shows the number of Postcode Address File (PAF) matched records in AddressBase by epoch:

Next release

The next release of AddressBase products, Epoch 116, is scheduled for 06 February 2025.

AddressBase Products April 2024 – Epoch 109

This release note provides information about the April 2024 release of the AddressBase products. These products were released to customers on 05 April 2024.

Record Counts

Product

Full Supply Record Count[1]

Change-Only Update Record Count[2]

OS OpenUPRN

40 744 085

N/A

AddressBase

30 440 058

141 664

AddressBase Plus

38 013 634

641 116

AddressBase Premium

See rows below

Street

1 504 346

5 403

Street Descriptor

1 627 151

2 603

BLPU

40 744 085

1 651 993

Classification

44 612 110

167 219

LPI

45 869 982

152 914

Organisation

1 415 880

17 270

Delivery Point Address

30 544 920

69 763

Application Cross Ref.

197 640 540

614 650

Successor

Change-Only Updates are not available for the OS Open UPRN product.
These counts are based on a Managed Great Britain Set (MGBS). If you have ordered your national coverage via the online ordering system using a polygon outline, then your counts may differ.

Product Supply Comparison

The national AOI refers to the pre-selection GB polygon from our download store. Therefore, if you have drawn your own AOI, the count will vary.

If you are unsure of your supply type, please check this with your OS Relationship Manager.

Product

MGBS Full Count

National AOI Full Count

Difference

AddressBase

30 440 058

AddressBase Plus

38 013 634

38 013 615

AddressBase Premium

See rows below

Street

1 504 346

1 504 345

Street Descriptor

1 627 151

1 627 150

BLPU

40 744 085

40 744 062

Classification

44 612 110

44 612 087

LPI

45 869 982

45 869 958

Organisation

1 415 880

1 415 878

Delivery Point Address

30 544 920

Application Cross Ref.

197 640 540

197 640 517

Successor

Changed Records

If you receive a Change-Only Update (COU) supply for your AddressBase product, you will receive Insert, Update and Delete records within the supplied file. The following tables detail the numbers of these records which can be expected in an MGBS supply,and also how many tiles are affected if you take your supply as Changed Chunks.

AddressBase

Change Type

Count

Inserts

38 002

Updates

91 196

Deletes

12 466

COU Populated Tile Count

5 410

AddressBase Plus

Change Type

Count

Inserts

55 152

Updates

571 494

Deletes

14 470

COU Populated Tile Count

7 157

AddressBase Premium

AddressBase Premium Table

Inserts

Updates

Deletes

Street

1 560

3 826

Street Descriptor

1 603

982

BLPU

54 407

1 594 091

3 495

Classification

68 978

75 921

22 320

LPI

67 818

80 668

4 428

Organisation

7 066

5 090

5 114

Delivery Point Address

38 799

18 094

12 870

Application Cross Ref.

225 972

348 380

40 298

Source Data Currency

The following information relates to the currency of the source data used in the creation of Epoch 109:

Data Source

Date

Royal Mail PAF

01 March 2024

National Land and Property Gazetteer

01 March 2024

One Scotland Gazetteer

12 February 2024

VOA Non-Domestic Rates

26 February 2024

VOA Council Tax

26 February 2024

OS MasterMap Topography Layer

20 February 2024

OS MasterMap Highways Network

06 February 2024

Code-Point with Polygons

04 January 2024

Boundary-Line

03 October 2023

Data Issues

AddressBase Plus Issues

Affected output formats: CSV and GML

There are 5 021 Unique Property Reference Numbers (UPRNs) which reference a Parent UPRN which cannot be found in the product. This is because the Parent UPRN is either provisional or historic and is not matched to the Royal Mail Postcode Address File (PAF) or Valuation Office Agency (VOA) record, meaning that it is not included in the AddressBase Plus product as per the existing background logic rules.
There are 254 records with a sao_start_no or sao_text that have no Parent UPRN in the product. This is because the Parent UPRN is a historical record which is included as part of the logic for record inclusion in the AddressBase Plus product.

Improvements in Epoch 109

Valuation Office Agency Matching

The match rates for Council Tax and Non-Domestic Rates for Epoch 109 are detailed as follows based on Valuation Office Agency (VOA) records up to 26 February 2024. The match rate is applicable to the AddressBase Premium product.

Data Source

Records Received

% Matched

Council Tax

27 033 727

99.95

Non-Domestic Rates

2 120 769

96.58

Tertiary Classifications

Work is being undertaken to improve the classifications of records within the AddressBase products. This work has resulted in 47 161 more tertiary classifications present in Epoch 109 compared to Epoch 108. Indeed, 88.77% of these tertiary classification improvements are against residential codes.

PAF Matching

The following graph shows the number of Postcode Address File (PAF) matched records in AddressBase by epoch:

Notification of Epoch 109’s Improvement in Historic BLPU State Code Completeness and Large Release Size

Summary

This release includes an enhancement in the clarity and consistency of lifecycle representation within product.

A conformance improvement has been delivered for BLPU State attribute for records where the BLPU Logical Status was 8 (historic) and BLPU State was null; for increased completeness, BLPU State Code has been populated with value 4 (no longer existing) and date stamped for the change applied.

Issue description

The BLPU state identifies the current lifecycle stage of a property (or object) and is additional to the mandatory LOGICAL_ STATUS field.

The BLPU code is an optional attribute for Local Authority Custodians to complete and therefore this attribute may be NULL in product.

An improvement to the completeness of the BLPU State Code was identified as a quality enhancement for lifecycle information as values for BLPU state code 4 can be accurately inferred from a Logical Status of 8. This enhancement allows the data to be interpreted more easily by removing conflict between addresses with a historic logical status and no BLPU state.

All nations within GB and the Islands product regions will benefit from this improvement, as such, it impacts approximately 1.2 million records for a Full Supply.

Impact

This quality improvement means a larger than usual supply of COUs in this release.

Next Release

The next release of AddressBase products, Epoch 110, is scheduled for 16 May 2024.

Searching for addresses

A common requirement for customers using the AddressBase products is to search for properties using full or partial addresses. Address searches may return a large number of addresses, a short list of possibilities, a single match or no results, depending on the search criteria.

There are many methods of implementing an address search, from free text queries through to structured address component searches. This guide will step through two such approaches that may be used when working with AddressBase and/or AddressBase Plus.

These methods are not intended as recommendations; they are merely examples of how to get maximum value out of the product when implementing an address search function.

Free text search

One type of search implementation involves a single ‘search engine’ style text box, into which a user can type all or some of an address. For example:

Find address

Results

CLOVER AVENUE, SW99 9ZZ

1, Clover Avenue, Fieldtown, Addressville, SW99 9ZZ

2, Clover Avenue, Fieldtown, Addressville, SW99 9ZZ

3, Clover Avenue, Fieldtown, Addressville, SW99 9ZZ

4, Clover Avenue, Fieldtown, Addressville, SW99 9ZZ

5, Clover Avenue, Fieldtown, Addressville, SW99 9ZZ

6, Clover Avenue, Fieldtown, Addressville, SW99 9ZZ

7, Clover Avenue, Fieldtown, Addressville, SW99 9ZZ

In this scenario, the user can choose to type anything in Find address, which may be just one component of an address (for example, a postcode, street name or building name), several parts of an address (for example, street name + town name, house name + postcode, etc.) or even (rarely) a complete address.

There may or may not be commas between search items, or address components can be entered with or without capitalised letters, etc. In short, with this search method, there is no structure to the user input and the search methodology must be designed with this in mind.

Structured component search

The other common type of implementation for address searches involves entering search criteria in a structured way (for example, with a different text box for each major address component).

Results

Rose Cottage, Main Street, Fieldtown, Addressville, SW99 9ZZ

Rose Cottage, Main Street, Ashford, AS45 9PP

Rose Cottage, Main Street, Buxtew, Monley, MO88 4TY

And so on...

This method guides the user to enter known components of an address and creates a predictable user input structure around which to build a search function. While generally simpler to use and implement, it can be less user-friendly, particularly in cases where it is not obvious which box to type an address component into, for example, is Richmond Terrace a building name or a street?

The search operation

This guide suggests how to implement the two search methods described above. Both should be used alongside the instructions on formatting single address labels.

The methods described here may be adapted to work with both AddressBase Plus, AddressBase Plus Islands and AddressBase; however, in the case of AddressBase, only Delivery Point Addresses are searchable, so the geographic guidance will not apply to this product.

An address search operation typically requires two stages of interaction from a user and several processing steps from the underlying IT system. These steps can be summarised in the following diagram:

The second user interaction can be omitted if there is only one result returned from the query. In almost all cases, there should be an option to ‘search again’ at the second and third stages in case no results are returned, or if none of the options shown is the required address.

Of course, different applications require different approaches; however, the general principles of the above process apply in all cases where an address is searched for based on user-entered criteria.

Generating a search query from structured user input

Within an interface that accepts structured user input for an address search, it is necessary to ‘map’ the fields presented to the user with those found within AddressBase or AddressBase Plus. In particular, any query will need to test multiple fields for a given input and will need to combine result sets from the two different address formats of AddressBase Plus (or the single address format of AddressBase) in order to produce the most complete result set.

Generally, a search form will describe a simplified view of an address in order to keep the user interface tidy and intuitive. Users may be given a set of text boxes to fill in, generally including building name, building number, street name, locality name, town name and postcode. The relationships between some common search fields and the fields found in AddressBase Plus are as follows:

Search Box

Mapped Delivery Point fields

Mapped geographic fields

Business Name

Organisation_Name

Organisation

PAO_Text

SAO_Text

Flat/Subdivision Name

Sub_Building_Name Department_Name

SAO_Text

Flat/Subdivision Number

Sub_Building_Name

SAO_StartNumber SAO_StartSuffix SAO_EndNumber

SAO_EndSuffix

Building Name

Building_Name

PAO_Text

Building Number

Building_Number

Building_Name (in cases where a suffix or range is present)

PAO_StartNumber PAO_StartSuffix PAO_EndNumber

PAO_EndSuffix

Street

Thoroughfare Dependent_Thoroughfare

Street PAO_Text

Locality

Dependent_Locality Double_Dependent_Locality

Locality Town Street

Town

Dependent_Locality Post_Town

Town Locality

Postcode

Postcode

Postcode_Locator

The above mapping is an example only, and it is possible to breakdown the search fields differently, in which case, a different mapping would be required. The important thing is to consider all possibilities for how data might be recorded. For example, a business name can sometimes appear as an organisation name or a building/PAO name depending on circumstances, so both must be checked when creating a search query.

Numbers need to be handled very carefully due to the presence of suffixes and ranges. There are two options for structuring the search input in these cases:

A single ‘number’ box can be used (as shown above in Flat/Subdivision Number and Building Number), which will then require some string manipulation to split the input into the appropriate numeric range and suffix components in order to search the geographic addresses; or
Four boxes can be provided for each number (start number, start suffix, end number and end suffix), which would then need to be combined into an appropriate string to search the Delivery Point Addresses.

Structuring the query for a structured address search

The basic rules to adhere to when generating a search query from structured input are as follows:

Ignore any search boxes that are not filled in with values.
Where a value is entered, assume that a match on at least one of the mapped fields is essential.

In SQL query terms, this means that each search term should generate a sub-query that searches each of the mapped fields (using OR), and that these sub-queries should then be combined together (using AND) into a single search query. The following SQL code illustrates this (for the Delivery Point Address search only) for an example where a street, locality and town name have been entered by the user:

SELECT dp.UPRN, GetFormattedAddress(dp.*) FROM abp dp

WHERE (dp.thoroughfare = streetsearchtext OR dp.dependent_thoroughfare = streetsearchtext) AND (dp.dependent_locality = localitysearchtext OR dp.double_dependent_locality = localitysearchtext) AND (dp.dependent_locality = townsearchtext OR dp.post_town = townsearchtext)

On top of this, for a complete query, the two different types of addresses should be queried separately (Geographic and Delivery Point Addresses), and the two result sets should be amalgamated into a single set using a UNION. The following example builds upon the previous example to include Geographic Addresses as well as Delivery Point Addresses.

SELECT UPRN, GetFormattedAddress(*) FROM abp

WHERE (thoroughfare = streetsearchtext OR dependent_thoroughfare = streetsearchtext) AND (dependent_locality = localitysearchtext OR double_dependent_locality = localitysearchtext) AND (dependent_locality = townsearchtext OR post_town = townsearchtext)

UNION

SELECT uprn, GetFormattedAddress(*) FROM abp WHERE (.street_name = streetsearchtext OR .pao_text = streetsearchtext) AND
(.locality = localitysearchtext OR .town = localitysearchtext OR .street_name = localitysearchtext) AND (.town = townsearchtext OR .locality = townsearchtext)

The SQL UNION operator will combine the two result sets, discarding any exact duplicates. (Retaining the exact duplicates requires the use of UNION ALL, but that is not desirable in this example.)

The resulting output from this query will be a set of search results as formatted addresses along with their UPRN. Exact duplicates will be omitted, but all ‘variations’ of the same address will be output (one row for each variation, with the same UPRN repeated more than once potentially). It may be wise to return the Postal Address Flag values against each to enable further filtering, for example, to restrict the results to postal addresses only. Note that the Postal Address Flag is only available in AddressBase Plus. All records in AddressBase are deemed postal as they are from Royal Mail’s PAF data.

Supporting case-insensitive queries and partial matches

A flaw in the above examples is the use of equality operators. In practice, because people do not tend to be consistent with capitalisation of letters, the SQL ‘LIKE’ operator might work better, and depending on the nature of the application, a ‘%’ wildcard could be appended to the end of each search term to allow only the first few letters of an address component to be entered. For example:

post_town LIKE townsearchtext -- Case insensitive search in some databases ;
post_town LIKE (townsearchtext || ‘%’) -- Matches post towns that start with the search text ;
post_town LIKE (‘%’ || townsearchtext || ‘%’) -- Matches post towns that contain the search text;

Alternatively, if exact matches are required but case sensitivity is not, then the UPPER() or LOWER() SQL functions can be used on each side of the equals sign in comparisons (a solution that should work in all databases):

UPPER(post_town) = UPPER(townsearchtext) -- Case insensitive equality;

Finally, to combine all of the approaches, the following would work for maximum flexibility:

UPPER(post_town) LIKE (‘%’ || UPPER(townsearchtext) || ‘%’)

Generating a search query from unstructured user input

When offering a ‘search engine’ style search feature with just a single text box to enter search terms, a wholly different approach is required. No assumptions can be made about the order, format or style of the user input, and the data will need to be ‘indexed’ in a way that facilitates searches of this type.

Creating a search index for addresses

Search engine style searches are likely to require the creation of an additional index/lookup table for addresses. Such a table is likely to consist of just two main columns: a key value (UPRN) and a formatted address string. Additional columns may be required to allow filtering of results (such as the AddressBase Postal flag values from AddressBase Plus, which would allow the results to be filtered by different address statuses).

The following table shows a possible address index table structure:

UPRN

Address Text

Statuses (multiple fields)

123456789012

4 THE MEADOWS HIGH STREET WALTHAMSDALE BURRIDGE BU27 9UB

Local Authority

123456789012

FLAT 4 THE MEADOWS HIGH STREET WALTHAMSDALE BURRIDGE BU27 9UB

PAF

123456789013

4 HIGH STREET WALTHAMSDALE BURRIDGE BU27 9UB

Non-postal

Note how the addresses have been formatted as a single text string with a single space between each word (although leaving commas in would do no harm). All forms of each address (both PAF and geographic) have been added to the index, so there can be several rows with the same UPRN. To speed up complex searching, an appropriate index could be added to the Address Text field, such as a full text search index.

Structuring the query for an unstructured address search

Once a suitable search index is in place, the query itself can be put together. The basic idea is to split the user input into search terms by removing commas, double spaces, and other unnecessary whitespace and then splitting it at each single space, as follows:

User input: 4, High Street, westville, wv17

Capitalised, with commas and double-spaces removed:

4 HIGH STREET WESTVILLE WV17

Split into separate search terms:

4
HIGH
STREET
WESTVILLE
WV17

Once the user input has been pre-processed into separate search terms, a query can be generated. The key assumption in this example will be that ALL search terms must be matched against the index table to be considered as a result. This implies a query where each value is matched using an ‘AND’ operator. In order to search the whole index, the ‘LIKE’ operator will need to be used along with a ‘%’ wildcard on either side of the search text. A suitable search query for the above example would be as follows:

SELECT UPRN, AddressText FROM AddressSearchIndex 
WHERE
AddressText LIKE ‘%4%’ AND 
AddressText LIKE ‘%HIGH%’ AND 
AddressText LIKE ‘%STREET%’ AND 
AddressText LIKE ‘%WESTVILLE%’ AND 
AddressText LIKE ‘%WV17%’;

This query would return all rows from the index table that contain all of the search terms, along with the appropriate UPRNs. The following table shows how the index table would be used in the above example to return relevant results:

Address text

Statuses (multiple fields)

894756389092

4 HIGH STREET WESTVILLE SUNNYTOWN WV17 7HL

Geographic + PAF

894756389132

ROSE COTTAGE 4 HIGH STREET WESTVILLE SUNNYTOWN WV17 7HL

Geographic

274859037849

FLAT 4 HIGHBURY COURT HIGH STREET WESTVILLE SUNNYTOWN WV17 7HL

Geographic + PAF

482974769830

MAPS4U LTD HIGH STREET WESTVILLE SUNNYTOWN WV17 7HL

Geographic + PAF

This result set can then be presented to the user, who can select the most appropriate record, which can then be retrieved in full using the UPRN.

Of course, in a practical implementation, the above query would need to be dynamically generated, with a separate condition added for each search term. This example is quite a strict search query that requires all search terms to be present. Many layers of complexity could be added to allow partial and ‘fuzzy’ matches, and to return confidence scores, for example, but such enhancements are beyond the scope of this guide.

Summary

This guide is intended as an introduction to implementing address search functionality using AddressBase, AddressBase Plus and AddressBase Plus Islands. The following list is a summary of the main points:

A user front-end for an address search may contain a single, search engine style text box or multiple text boxes representing different parts of an address.
A typical address search function takes place in three stages:
- A user enters search text.
- A query is run, returning a set of possible matches.
- The user selects the address of interest and the full record is then returned.
With a structured search interface, the addresses can be queried directly by mapping the various address fields to the text boxes supplied.
For an unstructured (single text box) interface, it is necessary to create an index table with fully formatted address strings against each UPRN. Queries can then be run against this index table by splitting the user input into individual search terms and requiring them all to be present.
It is possible to filter results by status in AddressBase Plus (for example, postal or non-postal).
Any search function should search all forms of an address (both Geographic and Delivery Point Addresses).
Careful consideration should be given to the use of ‘fuzzy’ search algorithms (such as using wildcard or sound-alike searches).

Address

This address record follows the lifecycle of a Postcode Address File (PAF) record matched to a Local Authority record. As a matched record is inserted, deleted and updated within PAF, these changes are incorporated into the AddressBase product. Similarly, if the matched Local Authority address record updates an attribute contained within the AddressBase product, this change will be reflected.

Feature type attributes

The following sub-sections provide details about the attributes included with this feature, their data types in the different output formats, and other important metadata about them.

The following sub-sections provide details about the attributes included with the Address feature type.

UPRN

Unique Property Reference Number (UPRN) assigned by the LLPG Custodian or Ordnance Survey.

Attribute Name: uprn (GML), UPRN (CSV)
Data Type: Integer (GML), Integer (CSV)
Multiplicity: [1]
Size: 12
Source: Contributing Local Authority / Ordnance Survey

TOID:

Unique identifier provided by Ordnance Survey.

Attribute Name: osAddressTOID (GML), OS_ADDRESS_TOID (CSV)
Data Type: LocalisedCharacterString (GML), char (CSV)
Multiplicity: [0..1]
Size: 20
Source: Ordnance Survey

UDPRN

Royal Mail’s Unique Delivery Point Reference Number (UDPRN).

Attribute Name: udprn (GML), UDPRN (CSV)
Data Type: Integer (GML), Integer (CSV)
Multiplicity: [1]
Size: 8
Source: Royal Mail

Organisation name

The organisation name is the business name given to a delivery point within a building or small group of buildings. For example: TOURIST INFORMATION CENTRE

This field could also include entries for churches, public houses and libraries.

Attribute Name: organisationName (GML), ORGANISATION_NAME (CSV)
Condition: Organisation Name or PO Box Number must be present if Building Name or Building Number are all not present.
Data Type: LocalisedCharacterString (GML), char (CSV)
Multiplicity: [0..1]
Size: 60
Source: Royal Mail

Department name

For some organisations, department name is indicated because mail is received by subdivisions of the main organisation at distinct delivery points. For example, Organisation Name: ABC COMMUNICATIONS or RM Department Name: MARKETING DEPARTMENT

Attribute Name: departmentName (GML), DEPARTMENT_NAME (CSV)
Condition: If a Department Name is present, an Organisation Name must also be present.
Data Type: LocalisedCharacterString (GML), char (CSV)
Multiplicity: [0..1]
Size: 60
Source: Royal Mail

Po box number

Post Office Box (PO Box) number.

Attribute Name: poBoxNumber (GML), PO_BOX_NUMBER (CSV)
Condition: Organisation Name or PO Box Number must be present if Building Name or Building Number are all not present.
Data Type: CharacterString (GML), char (CSV)
Multiplicity: [0..1]
Size: 6
Source: Royal Mail

Sub building name

The sub-building name and/or number are identifiers for subdivisions of properties.

For example: Sub-building Name: FLAT 3, Building Name: POPLAR COURT, Thoroughfare: LONDON ROAD

If the above address is styled 3 POPLAR COURT, all the text will be shown in the Building Name attribute and the Sub-building Name will be empty. The building number will be shown in this field when it contains a range, decimal or non-numeric character (see Building Number).

Attribute Name: subBuildingName (GML), SUB_BUILDING_NAME (CSV)
Condition: If a Sub Building Name is present, a Building Name or Building Number must also be present.
Data Type: LocalisedCharacterString (GML), char (CSV)
Multiplicity: [0..1]
Size: 30
Source: Royal Mail

Building name

The building name is a description applied to a single building or a small group of buildings, such as Highfield House. This also includes those building numbers that contain non-numeric characters, such as 44A.

Some descriptive names, when included with the rest of the address, are sufficient to identify the property uniquely and unambiguously, for example, MAGISTRATES COURT.

Sometimes the building name will be a blend of distinctive and descriptive naming, for example, RAILWAY TAVERN (PUBLIC HOUSE) or THE COURT ROYAL (HOTEL).

Attribute Name: buildingName (GML), BUILDING_NAME (CSV)
Condition: Building Name must be present if Organisation Name or Building Number or PO Box Number are all not present.
Data Type: LocalisedCharacterString (GML), char (CSV)
Multiplicity: [0..1]
Size: 50
Source: Royal Mail

Building number

The building number is a number given to a single building or a small group of buildings, thus identifying it from its neighbours, for example, 44. Building numbers that contain a range, decimals or non-numeric characters do not appear in this field but will be found in the buildingName or the sub-BuildingName fields.

Attribute Name: buildingNumber (GML), BUILDING_NUMBER (CSV)
Condition: Building Number must be present if Organisation Name or Building Name or PO Box Number are all not present.
Data Type: Integer (GML), Integer (CSV)
Multiplicity: [0..1]
Size: 4
Source: Royal Mail

Thoroughfare

A thoroughfare in AddressBase is fundamentally a road, track or named access route on which there are Royal Mail delivery points, for example, HIGH STREET.

Attribute Name: thoroughfare (GML), THOROUGHFARE (CSV)
Data Type: LocalisedCharacterString (GML), char (CSV)
Multiplicity: [0..1]
Size: 80
Source: Royal Mail

Post town

The town or city in which the Royal Mail sorting office is located which services this record. There may be more than one, possibly several, sorting offices in a town or city.

Attribute Name: postTown (GML), POST_TOWN (CSV)
Data Type: LocalisedCharacterString (GML), char (CSV)
Multiplicity: [1]
Size: 30
Source: Royal Mail

Double dependent locality

This is used to distinguish between similar thoroughfares or the same thoroughfare within a dependent locality. For example, Millbrook Industrial Estate and Cranford Estate in this situation: BRUNEL WAY, MILLBROOK INDUSTRIAL ESTATE, MILLBROOK, SOUTHAMPTON and BRUNEL WAY, CRANFORD ESTATE, MILLBROOK, SOUTHAMPTON.

Attribute Name: doubleDependentLocality (GML), DOUBLE_DEPENDENT_LOCALITY (CSV)
Data Type: LocalisedCharacterString (GML), char (CSV)
Condition: If a Double Dependent Locality is present, a Dependent Locality must also be present.
Multiplicity: [0..1]
Size: 35
Source: Royal Mail

Dependent locality

Dependent locality areas define an area within a post town. These are only necessary for postal purposes and are used to aid differentiation where there are thoroughfares of the same name in the same locality. For example, HIGH STREET in SHIRLEY and SWAYTHLING in this situation: HIGH STREET, SHIRLEY, SOUTHAMPTON and HIGH STREET, SWAYTHLING, SOUTHAMPTON.

Attribute Name: dependentLocality (GML), DEPENDENT_LOCALITY (CSV)
Data Type: LocalisedCharacterString (GML), char (CSV)
Multiplicity: [0..1]
Size: 35
Source: Royal Mail

Postcode

A postcode is an abbreviated form of address made up of combinations of between five and seven alphanumeric characters. These are used by Royal Mail to help with the automated sorting of mail. A postcode may cover between 1 and 100 addresses.

There are two main components of a postcode, for example, NW6 4DP:

The outward code (or ‘outcode’). The first two–four characters of the postcode constituting the postcode area and the postcode district, for example, NW6. It is the part of the postcode that enables mail to be sent from the accepting office to the correct area for delivery.
The inward code (or ‘incode’). The last three characters of the postcode constituting the postcode sector and the postcode unit, example, 4DP. It is used to sort mail at the local delivery office.
Attribute Name: postcode (GML), POSTCODE (CSV)
Data Type: CharacterString (GML), char (CSV)
Multiplicity: [1]
Size: 8
Source: Royal Mail

Postcode type

Describes the address as a small or large user as defined by Royal Mail.

Attribute Name: postcodeType (GML), POSTCODE_TYPE (CSV)
Condition: If PO Box number is present Postcode Type must be ‘L’.
Multiplicity: [1]
Size: 1
Source: Royal Mail

Position

A value in metres defining the x and y location in accordance with the British National Grid.

Attribute Name: position (GML), X_COORDINATE, Y_COORDINATE (CSV)
Data Type: GM_Point (GML), Float (CSV)
Multiplicity: [1]
Size: X_COORDINATE (precision, scale) – (8, 2), Y_COORDINATE (precision, scale) – (9, 2)
Source: Contributing Local Authority/Ordnance Survey

Position lat long

A value defining the Longitude and Latitude location in accordance with the ETRS89 coordinate reference system.

Attribute Name: positionLatLong (GML), LATITUDE, LONGITUDE (CSV)
Data Type: GM_Point (GML), Float (CSV)
Multiplicity: [1]
Size: LATITUDE (precision, scale) – (9, 7), LONGITUDE (precision, scale) – (8, 7)
Source: Ordnance Survey

RPC

Representative Point Code. This code is used to reflect positional accuracy.

Attribute Name: rpc (GML), RPC (CSV)
Multiplicity: [1]
Size: 1
Source: Contributing Local Authority

Country

The country in which a record can be found.

Attribute Name: country (GML), COUNTRY (CSV)
Multiplicity: [1]
Size: 1

Change type

Type of Record Change – please see Section 4 for more information.

Attribute Name: changeType (GML), CHANGE_TYPE (CSV)
Multiplicity: [1]
Size: 1

LA start date

The date on which the address record was inserted into the database in the CCYY-MM-DD format.

Attribute Name: laStartDate (GML), LA_START_DATE (CSV)
Data Type: Date (GML), Date (CSV)
Multiplicity: [1]
Source: Contributing Local Authority

RM start date

Date on which the Royal Mail address was loaded into the NAG (National Address Gazetteer in the CCYY-MM-DD format – as maintained by Geoplace) hub.

Attribute Name: rmStartDate (GML), RM_START_DATE (CSV)
Data Type: Date (GML), Date (CSV)
Multiplicity: [1]
Source: Royal Mail

Last update date

The date on which any of the attributes on this record were last changed in the CCYY-MM-DD format.

Attribute Name: lastUpdateDate (GML), LAST_UPDATE_DATE (CSV)
Data Type: Date (GML), Date (CSV)
Multiplicity: [1]

Class

Primary classification of the address record. For example, identifying the record as commercial (value of ‘C’) or residential (value of ‘R’).

Attribute Name: class (GML), CLASS (CSV)
Data Type: CharacterString (GML), char (CSV)
Multiplicity: [1]
Size: 1
Source: Contributing Local Authority

Creating a single-line or multi-line address

The AddressBase products provide a variety of data fields, allowing you to construct different forms of an address for a given addressable object, dependent on how the address is to be used.

AddressBase contains the Delivery Point Address which is sourced from Royal Mail’s Postcode Address File (PAF) – a non-geocoded list of addresses. These addresses are used primarily as a ‘mailing list’ for postal purposes.

There are two types of address contained in the AddressBase Plus products:

Delivery Point Address
Geographic Address

These two address types come from different sources and are matched together by GeoPlace.

As noted above, the Delivery Point Address is sourced from Royal Mail’s PAF data. Geographic Addresses are maintained by contributing Local Authorities. The structure of a Geographic Address is based on the British Standard BS7666. These addresses are used to provide an accurate geographic locator for an object to support, for example, service delivery, asset management, or command and control operations. They also represent the legal form of addresses as created under street naming and numbering legislation.

Each UPRN in AddressBase Plus provides the Geographic Address and, where matched, the Delivery Point Address in a one-to-one relationship. If there is no match, then the following fields will be left empty:

DEPARTMENT_NAME

ORGANISATION_NAME

SUB_BUILDING_NAME

BUILDING_NAME

BUILDING_NUMBER

PO_BOX_NUMBER

DEPENDENT_THOROUGHFARE (and WELSH_DEPENDENT_THOROUGHFARE)

THOROUGHFARE (and WELSH_THOROUGHFARE)

DOUBLE_DEPENDENT_LOCALITY (and WELSH_DOUBLE_DEPENDENT_LOCALITY)

DEPENDENT_LOCALITY (and WELSH_DEPENDENT_LOCALITY)

POST_TOWN (and WELSH_POST_TOWN)

POSTCODE

Background

A common requirement for customers using the AddressBase products is to build a single address label from core address elements.

There are two types of address label. The simplest is a full address on a single line with different elements separated by commas and spaces. This type of label is suited for displaying a full address within a tabular display, such as within an on-screen data grid or spreadsheet, or where a single-line printed address is most appropriate (such as within the text, header or footer of a letter):

ROSE COTTAGE, 5 MAIN STREET, ADDRESSVILLE, LONDON, SE99 9EX

The other type of formatted address is a multi-line address label. These are most often used on envelopes or at the tops of letters, where different parts of an address are separated onto different lines:

ROSE COTTAGE

5 MAIN STREET

ADDRESSVILLE LONDON

SE99 9EX

The rules in this guide are suggestions only and can be used for visual display of full addresses. It is strongly recommended that address components are stored in the format in which they are provided in order to allow maximum flexibility of use and derived value.

Delivery Point Address (PAF Address)

A Delivery Point Address contains information sourced from Royal Mail (PAF). Stringent rules are used to match these addresses to the Geographic Address and assign a common UPRN to link addresses from the two addressing sources together in the data model.

To construct a single address label based purely on the Royal Mail PAF address fields, the following attributes can be used to build a Delivery Point Address label.

The table below provides details of the Delivery Point Address Components.

Delivery Point Address Component

Type

DEPARTMENT_NAME

Character

ORGANISATION_NAME

Character

SUB_BUILDING_NAME

Character

BUILDING_NAME

Character

BUILDING_NUMBER

Integer

PO_BOX_NUMBER

Integer

DEPENDENT_THOROUGHFARE (or WELSH_DEPENDENT_THOROUGHFARE)

Character

THOROUGHFARE (or WELSH_THOROUGHFARE)

Character

DOUBLE_DEPENDENT_LOCALITY (or WELSH_DOUBLE_DEPENDENT_LOCALITY)

Character

DEPENDENT_LOCALITY (or WELSH_DEPENDENT_LOCALITY)

Character

POST_TOWN (or WELSH_POST_TOWN)

Character

POSTCODE

Character

These address components are listed in the correct order in which they should appear on an address label. There may be a business need to replace the thoroughfare, locality and post_town attributes with the Welsh equivalent. The following examples use the English version of these attributes only.

It should be noted that most of the PAF fields are optional and may contain null values (or zero, in the cases of ‘BUILDING NUMBER’ and ‘PO BOX NUMBER’). In these cases, those fields should be omitted.

The following (entirely fictional) example shows all of the PAF fields filled in (apart from the PO Box number) and indicates how they should be ordered in a single address label.

Delivery Point Address Component

Example

DEPARTMENT_NAME

CUSTOMER SERVICE DEPARTMENT

ORGANISATION_NAME

JW SIMPSON LTD.

SUB_BUILDING_NAME

UNIT 3

BUILDING_NAME

THE OLD FORGE 7

BUILDING_NUMBER

PO_BOX_NUMBER

DEPENDENT_THOROUGHFARE

RICHMOND TERRACE

THOROUGHFARE

MAIN STREET

DOUBLE_DEPENDENT_LOCALITY

HOOK

DEPENDENT_LOCALITY

WARSASH

POST_TOWN

SOUTHAMPTON

POSTCODE

SO99 9ZZ

In cases where a PO BOX NUMBER is present, it will only be described in the data as an integer. In order to properly format these addresses when generating an address label, these integers should be prefixed with the text ‘PO BOX’, as shown in the following example:

Delivery Point Address Component

Data Content

Formatted output

ORGANISATION_NAME

‘JWS CONSULTING’

JWS CONSULTING

PO_BOX_NUMBER

5422

PO BOX 5422

THOROUGHFARE

‘HIGH STREET’

HIGH STREET

POST_TOWN

'SPRINGFIELD’

SPRINGFIELD

POSTCODE

‘SP77 0SF’

SP77 0SF

Where null or empty, string values exist (for character fields) or zeros or nulls (for integer fields), those fields should be entirely omitted from the output. However, the order in which the fields should be concatenated always remains the same.

Delivery Point Address Component

Data content

Formatted output

DEPARTMENT_NAME

Null

ORGANISATION_NAME

‘TM MOTORS’

TM MOTORS

SUB_BUILDING_NAME

Null

BUILDING_NAME

‘THE OLD BARN’

THE OLD BARN

BUILDING_NUMBER

0 (or null)

PO_BOX_NUMBER

0 (or null)

DEPENDENT_THOROUGHFARE

Null

THOROUGHFARE

‘HORSHAM LANE’

HORSHAM LANE

DOUBLE_DEPENDENT_LOCALITY

Null

DEPENDENT_LOCALITY

Null

POST_TOWN

‘HORSHAM’

HORSHAM

POSTCODE

‘RH12 1EQ’

RH12 1EQ

Building a single-line Delivery Point Address

Building a single-line, formatted address for a Delivery Point is relatively straightforward. All the fields should be checked in the order shown previously in Table 1, and those that have values should be concatenated together into a single line. Generally, address components should be separated by a comma followed by a single space (‘, ’), although sometimes only a space is used between a building number and a thoroughfare name. You can use your preference.

The SQL operator for concatenating text is a double pipe (‘||’).
CASE blocks have been used to test each of the fields for null values before concatenating its contents (along with a suitable separator – either ‘, ’ or ‘ ’).
The field names and table names used are illustrative and may vary between databases.
Depending on the database schema and data loading method used, it may be necessary to test some fields for empty strings (‘’) or zero values (for integer fields) instead of, or as well as, testing for NULLs.
If you are using PostGres (PostGIS), it might be beneficial to substitute the ‘IS NOT NULL’ with != ‘’. This should improve the overall appearance of the output.

Building a multi-line Delivery Point Address

Splitting a Delivery Point Address into multiple lines is more complicated. There are several rules to consider in order to avoid having very short lines (for example, just a building number) or very long lines within the formatted address. A summary of these rules is as follows:

Generally, if there is a building number, it should appear on the same line as the thoroughfare (or dependent thoroughfare) name. If there is no thoroughfare name information, it should appear on the same line as the first locality name.
In cases where building numbers have been placed in the building name field due to the presence of a letter suffix (for example, ‘11A’) or a number range separator (for example, ‘3–5’), these should be detected and placed on the same line as the thoroughfare name in the same way as a building number (or on the first locality line if no thoroughfare name is present).
In most other cases, the building name, if present, should appear on a separate line above the thoroughfare (or dependent thoroughfare) name. If there is no thoroughfare name present, it should appear on the same line as the first locality name.
Similar tests should be applied to the SUB_BUILDING_NAME field: if this field contains a number, a number with a suffix, or a numeric range, it should precede the building name on the same line. In most other cases, it should appear on a separate line above the building name.

Geographic Address (Local Authority Address)

The structure of a Geographic Address is based on the British Standard BS7666 and is split into several components. This means that in order to construct a complete address label (for example, on an envelope, database form or GIS display), the components need to be constructed according to a set of rules.

Within the AddressBase Plus products, the core property level address information is stored within the Primary Addressable Object (PAO) and Secondary Addressable Object (SAO) fields. The additional attribution required to build a full address label are the la_organisation, street_description, locality, town_name, administrative_area and postcode_locator.

For a full description of PAOs and SAOs, and the complete set of AddressBase Plus fields, please refer to the Technical Specification on your respective product:

Constructing a single address label from the Geographic Address fields

To construct a single address label based purely on the BS7666 address fields, the following attributes should be used to build a Geographic Address label.

Geographic Address Component

Type

LA_ORGANISATION

Character

SAO_TEXT (or ALT_LANGUAGE_SAO_TEXT)

Character

SAO_START_NUMBER

Integer

SAO_START_SUFFIX

Character

SAO_END_NUMBER

Integer

SAO_END_SUFFIX

Character

PAO_TEXT (or ALT_LANGUAGE_PAO_TEXT)

Character

PAO_START_NUMBER

Integer

PAO_START_SUFFIX

Character

PAO_END_NUMBER

Integer

PAO_END_SUFFIX

Character

STREET_DESCRIPTION (or ALT_LANGUAGE_STREET_DESCRIPTION)

Character

LOCALITY

Character

TOWN_NAME

Character

ADMINISTRATIVE_AREA*

Character

POSTCODE_LOCATOR

Character

*ADMINISTRATIVE_AREA is optional because it is common for this field to be the same as the TOWN_NAME. Sometimes, however, this field will help users construct a more complete address.

These address components are listed in the correct order in which they should appear on an address label. There may be a business need to use alternate language fields for the SAO_TEXT, PAO_TEXT and STREET_DESCRIPTION, which are also listed in the correct order above.

Rendering SAOs and PAOs

When building a single address label, it may be necessary to concatenate the various SAO fields and PAO fields together respectively. These fields contain any property names, numbers, number ranges or suffixes that apply to an address.

A PAO number/range string should be constructed from the PAO_START_NUMBER, PAO_START_SUFFIX, PAO_ END_NUMBER and PAO_END_SUFFIX fields, as illustrated in the following table.

Attribute

Example 1

Example 2

Example 3

Example 4

PAO_START_NUMBER PAO_START_SUFFIX PAO_END_NUMBER PAO_END_SUFFIX

A 5 C

Rendered PAO range

1-5

1A-5C

Similarly, a SAO number/range string should be constructed from the SAO_START_NUMBER, SAO_START_SUFFIX, SAO_END_NUMBER and SAO_END_SUFFIX fields, as illustrated in the following table.

In addition to the numeric range fields described above, there are also PAO_text and SAO_text fields. These fields may be populated instead of, or as well as, the numeric range fields. In both cases, if both text and a numeric range string are present, the text should appear before the numeric range in any formatted address.

Attribute

Example 1

Example 2

Example 3

Example 4

PAO (number string) PAO (text)

Rose Cottage

Rendered PAO (showing street name location)

1 <street>

1A <street>

Rose Cottage, 1A

Rose Cottage,

For PAOs, there will always be either a text entry or a numeric/range entry, or both. This is not the case for SAOs, which may be entirely absent for a given address.

Street description, town, locality and administrative area names

The street description and administrative area names are always present, while the locality name and town name may be empty.

The ADMINISTRATIVE_AREA field always contains a value; however, this value will not always enhance an address, but in some cases it will. In particular, check that it is not the same as the value in the TOWN_NAME field, as this is often the case.

Administrative area not included

Administrative area included (BURY)

34, CROW LANE, RAMSBOTTOM, BL0 9BR

34, CROW LANE, RAMSBOTTOM, BURY, BL0 9BR

In other cases, the administrative area name will simply contain the local authority name, which would not traditionally form part of a single or multi-line address but can be included to add additional information to an address label. Its inclusion is largely down to business requirements or personal preference; however, it may also be useful to 'de-duplicate' some Geographic Addresses.

The following (entirely fictional) example shows all of the BS7666 Geographic Address fields filled in and how they should be ordered in a single address label.

Geographic Address Component

Example

LA_ORGANISATION SAO_TEXT

SAO (number/range string)* PAO_TEXT

PAO (number/range string)* STREET_DESCRIPTION LOCALITY

TOWN_NAME ADMINISTRATIVE_AREA

POSTCODE_LOCATOR

JW SIMPSON LTD THE ANNEXE

THE OLD MILL 7–9

MAIN STREET HOOK WARSASH SOUTHAMPTON

SO99 9ZZ

*The number/range strings are built from the relevant PAO/SAO START_NUMBER, START_SUFFIX, END_NUMBER and END_SUFFIX fields, as described above, and formatted as character strings.

Where an administrative area matches the town name, it should always be omitted.

Delivery Point Address Component

Data content

Formatted output

PAO_TEXT

‘HIGHBURY HOUSE’

HIGHBURY HOUSE

STREET_DESCRIPTION

‘HIGH STREET’

HIGH STREET

TOWN_NAME

‘SOUTHAMPTON’

SOUTHAMPTON

ADMINISTRATIVE_AREA

‘SOUTHAMPTON’

POSTCODE_LOCATOR

‘SO77 0SF’

SO77 0SF

Where null or empty string values exist (for character fields) or zeros or nulls (for integer fields), those fields should be entirely omitted from the output; however, the order in which the fields should be concatenated always remains the same.

Delivery Point Address Component

Data content

Formatted output

ORGANISATION

‘TM MOTORS’

TM MOTORS

SAO_TEXT

null

SAO (number/range string)*

null

PAO_TEXT

‘THE OLD BARN’

THE OLD BARN

PAO (number/range string)*

‘1’

STREET_DESCRIPTION

‘HORSHAM LANE’

HORSHAM LANE

LOCALITY

null

TOWN_NAME

‘HORSHAM’

HORSHAM

ADMINISTRATIVE_AREA

‘HORSHAM’

* Duplicate name omitted

POSTCODE_LOCATOR

‘RH12 1EQ’

RH12 1EQ

Building a single-line Geographic Address

The SQL operator for concatenating text is a double pipe (‘||’).
CASE blocks have been used to test each of the fields for null values before concatenating its contents (along with a suitable separator – either ‘, ’ or ‘ ’).
The field names and table names used are illustrative and may vary between databases.
Depending on the database schema and data loading method used, it may be necessary to test some fields for empty strings (‘’) or zero values (for integer fields) instead of or as well as testing for NULLs.

Building a multi-line Geographic Address

Splitting a Geographic Address into multiple lines is more complex. As with Delivery Point Addresses, there are several rules to consider in order to avoid having very short lines (for example, just a building number) or very long lines within the formatted address.

A summary of these rules is as follows:

Generally, if there is a PAO number/range string, it should appear on the same line as the Street Description. For example: 11A MAIN STREET
If there is a PAO_text value, it should always appear on the line above the Street Name (or on the line above the <PAO number string> + <Street Name> where there is a PAO number/range).
PAO_text only
PAO_text and PAO number or range
ROSE COTTAGE, MAIN STREET
ROSE COTTAGE, 11A MAIN STREET
If there is a SAO_text value, it should appear on a separate line above the PAO_text line (or the PAO number/range + Street Name where there is no PAO_text value).
SAO_text value only, with PAO_text value only
SAO_text value only, with PAO number/range only
THE ANNEXE, ROSE COURT, MAIN STREET
THE ANNEXE, 11A MAIN STREET
If there is a SAO number/range value, it should be inserted either on the same line as the PAO_text (if there is a PAO_text value), or on the same line as the PAO number/range + Street Name (if there is only a PAO number/range value and no PAO_text value). If there are both PAO_text and a PAO number/range, then the SAO number/range should appear on the same line as the PAO_text, and the PAO number/range should appear on the street line.
SAO number/range value only, and PAO_text value only
SAO number/range value only, and PAO number/range value only
SAO number/range value only, and both PAO_text and PAO number/range values
1A ROSE COURT, MAIN STREET
1-3, 11A MAIN STREET
1A ROSE COURT,
11A MAIN STREET
If there is a SAO_text value, it should always appear on its own line.
SAO_text value only with PAO_text only
SAO_text and SAO number/range and PAO_text and PAO number/range
THE ANNEXE, ROSE COTTAGE, MAIN STREET
WARDEN’S FLAT,
1A ROSE COURT,
11A MAIN STREET
If there is an Organisation Name, it should always appear alone as the top line of the address.
Organisation Name along with all PAO + SAO fields
COTTAGE INDUSTRY LTD, THE ANNEXE,
1A ROSE COURT,
11A MAIN STREET
The Locality (if present) should appear on a separate line beneath the Street Description, followed by the Town Name on the line below it. If there is no Locality, the Town Name should appear alone on the line beneath the Street Description.
Locality and Town Name present
Town Name only
[first part of address, formatted as described above] MAIN STREET,
HIGHFIELD, SOUTHAMPTON
[first part of address, formatted as described above] HIGH STREET,
SOUTHAMPTON
If the Administrative Area name is required and it is not a duplicate of the Town Name, it can optionally be included on a separate line beneath the Town Name.
Administrative Area name included
[first part of address, formatted as described above] MAIN STREET,
WINDSOR,
ROYAL BOROUGH OF WINDSOR AND MAIDENHEAD
Finally, the Postcode Locator should be inserted on the final line of the address.
With Postcode_Locator on final line
[first part of address, formatted as described above] HIGH STREET,
MILTON, ML99 0WW

Creating mailing lists

Given that AddressBase Plus contains two different types of address, a decision needs to be made as to whether to use the Geographic or Delivery Point Addresses, or a mixture.

The following two options should be considered:

Use Delivery Point Addresses whenever they are available, and when they are not, use a Geographic Address.
Use Geographic Addresses in all cases.

Depending on business requirements, in some user interfaces it may be worth considering displaying both forms of an address where possible, since this will provide the maximum information available about a given UPRN.

‘Mixing and matching’ components from the two different forms of address into a single address label is not recommended as this is likely to cause confusion in some instances.

Other filters

AddressBase Plus offers other attributes that could be used in conjunction with address labels. For example, classification can be used to target certain types of property, or OS MasterMap Topography TOID cross references can be used to link address labels to Topographic objects and viewed in a GIS.

TOID cross references are not available in AddressBase Plus Islands.

Working with CSV data

Preparing the CSV data

These instructions describe how to prepare the CSV format of AddressBase, AddressBase Plus and AddressBase Plus Islands data for processing.

Merging multiple CSV files

Unzip all the CSV files into a single folder. Ensure there are no spaces in your chosen folder path, for example: C:\AddressBase_Data or C:\AddressBase_Plus_Data or C:\AddressBase_Plus_Islands_Data.
We recommend merging all the CSV files together to save time importing individual files. You can do this manually using a text editor such as Notepad or TextPad, but it is much faster to use a .bat batch file or an MS-DOS command as described below.
To use the .bat batch function, copy the following text and paste it into a new Notepad document: copy *.csv mergedABdata.csv In this example, mergedABdata.csv is the output name of the merged file which will be created, but this can be any user-defined filename with the extension .csv.
Save the Notepad document with the file extension .bat (for example, mergedABdata.bat) in the same directory as the CSV files unzipped previously (for example, C:\AddressBase_Data or C:\AddressBase_Plus_Data).
Close the .bat file and navigate to the directory where you just saved it. Double-click on the .bat file (for example, mergedABdata.bat) and an MS-DOS window will run. Once the process is complete, the MS-DOS screen will close automatically.
If you look in the directory containing the AddressBase CSV files and batch file, you’ll see that there is now an additional single file called mergedABdata.csv (or the user-defined filename you picked when creating your batch file).

Loading CSV into GIS software

These instructions describe how to load the CSV format of AddressBase, AddressBase Plus and AddressBase Plus Islands data. In these examples, AddressBase Plus data will be used to describe the procedures in various GI systems.

Loading CSV into ArcGIS Pro

Note - These instructions are based on ArcGIS Pro version 2.3.3.

Launch ArcGIS Pro and start a new blank project.
Select a folder to save the project to.
Name your project and click OK. The project will then be created. Note - ArcGIS Pro automatically creates a new File Geodatabase (.gdb) within the project folder created. This is different to the creation process in the older ESRI application ArcMap.
You can add a backdrop map for contextual purposes from the available backdrop maps supplied by ESRI or add one of your own from a different File Geodatabase. In this example, we have added a light grey backdrop map canvas supplied by ESRI.
Open the Catalog pane on the right-hand side of the window and expand the listing to see the File Geodatabase created with the project.
To import the AddressBase or AddressBase Plus data, right-click the File Geodatabase, then select Import and from that sub-menu, select Table. A new Geoprocessing window will display in the right-hand pane.
Click the folder icon on the right-hand side of the Input Rows field. A new dialog will open.
Back in the Geoprocessing window, type a name in the Output Name field, then click Run at the bottom of the window.
Once the process has run, a green box will display at the bottom of the Geoprocessing window and the new AddressBase table will be listed in the left-hand panel.
The data has loaded as a non-geometry table.
To make the data visible against the mapping backdrop, the XY Coordinate fields need to be specified.
- In the Contents pane, right-click the AB_Plus table (or the output name you chose) and in the dropdown click Display XY data.
In the Geoprocessing window, the XY Table To Point parameters will be displayed.
- Using the dropdown options, change the X Field to X_COORDINATE or Longitude and the Y Field to Y_COORDINATE or Latitude.
- Then select Projected Co-ordinate Systems > National Grids > Europe > British National Grid. Note – If you selected X and Y as Longitude and Latitude in the step above, then you need to select ETRS89 [EPSG: 4258] instead.
Click Run.
Once the process has run, a green box will appear at the bottom of the Geoprocessing window and the output XYTableToPoint map layer should appear ticked on the left-hand Contents pane. In the Map window, the addresses will now be displayed as point features.
You have now successfully loaded the data in ArcGIS Pro.

Loading CSV into ArcGIS Desktop

Note - These instructions are based on ArcGIS Desktop versions 9.3 and 10.

Launch ArcCatalog as a separate program, or within ArcMap if you are using version 10.
Connect to a folder where the AddressBase data you wish to use can be accessed, for example, C:\AddressBase_Data or C:\AddressBase_Plus_Data. To do this:
- Click File, or select Folder Connections if you are using version 10.
- Click Connect Folder, or in version 10, right-click on Folder connections > Connect Folder and navigate to the relevant folder.
- From the main window, select the folder to connect to and click OK.
The folder should now appear in the navigation window to the left of the screen, or within your Catalog window if you have opened it within ArcGIS Map.
Create a File Geodatabase to store the address data. Using the file tree, go to folder connections and navigate to the directory where you wish to create the File Geodatabase, for example: C:\AddressBase_Geodatabase\AddressBase_Plus. This may need to be set up as a new connection as per the above.
Right-click on the folder where you the File Geodatabase should to be contained, then select New and File Geodatabase.
A File Geodatabase will be created and named by default as New File Geodatabase. Rename the File Geodatabase to a name of your choice.
Right-click on your new File Geodatabase, and select Import > Table (single)…
- For Input Rows, navigate to the location of the CSV data file that contains the merged header and AddressBase or AddressBase Plus data file.
- The Output Location should automatically populate with the location of the File Geodatabase that is to be updated; this should be the File Geodatabase you created above.
- Insert a relevant name for the Output Table, for example: AddressBase_data. Ensure that there are no spaces in the table name. This name will appear under your geodatabase.
Click OK.
To create a map of the locations of the AddressBase records, they need to be geocoded.
- Right-click on the AddressBase table in the geodatabase that you have just created and select Create Feature Class.
- In the XY Table… window, you can use the dropdowns to change the X Field to either X_COORDINATE or Longitude, and the Y Field to Y_COORDINATE or Latitude.
- Click on the Input Coordinates icon and navigate to Projected Co-ordinate Systems > National Grids > Europe > British National Grid. Note – If you selected X and Y as Longitude and Latitude in the step above, then you need to select ETRS89 [EPSG: 4258] instead.
Double-click on the chosen Coordinate System, then click Apply and OK.
Click on the folder icon alongside the Output field and navigate to the File Geodatabase you just created above. If you cannot see the File Geodatabase, ensure that the Save as type box at the bottom of the dialog box is set to File and Personal Geodatabase feature classes.
Type in a name for it and click Save.
Leave the Configuration keyword dropdown menu as DEFAULTS. Click OK. Note – You may need to right-click on the Personal Geodatabase where it was saved and select Refresh in order to see your points. At this stage, if you have completed the steps above in ArcCatalog and not within ArcMap, please continue to follow the steps below. Otherwise, if you have been using version 10 with the catalog inside ArcMap, the data can now be loaded into ArcMap.
In ArcMap, select File > Add Data and navigate to the folder where the File Geodatabase was created above.
Double-click on the File Geodatabase to open it, then select all the files inside.
Click Add.
Once the data has been loaded into ArcMap, you may wish to display more than the ESRI-defined Object ID in the Info tool. To change this:
- Double-click on the spatial dataset.
- Select the Fields tab.
- Change the Primary Display Field to your desired field, for example, UPRN.

Loading CSV into MapInfo Pro

Note - These instructions are based on MapInfo Pro version 12.

Note – MapInfo has a size limit of 2Gb on each table. This equates to a maximum number of approximately 4 million AddressBase records.

Launch MapInfo.
Cancel the Quick Start prompt.
Click File > Open and navigate to the folder that contains the AddressBase data.
In the Files of Type dropdown menu, select Comma delimited CSV (*.csv), then click on the AddressBase data to be loaded. Click Open.
In the next window, tick the Use First Line for Column Titles box and select the character set INSERT CHARACTER SET. Click OK. Note – When adding data this way, the field type classifications and field sizes of each column automatically try to fit the type of data that MapInfo believes is contained within the column and the largest value of that classification found within that column. This means that the classifications and field sizes of some attributes may not match the field types and sizes stated in the Technical Specification. The following instructions outline how to change these columns to match those values:
Select File > Save Copy As… and select the AddressBase table that was loaded. Select Save As… and name the table to be created, then click Save.
Open the table that was just created via File > Open. Navigate to and select the copy of the table you just named. Click Open.
Navigate to Table > Maintenance > Table Structure and select the table to be edited. Click OK.
Here you can change the Type and Width of each attribute to match the ones stated in the technical specification:
Type and Width should be changed for all attributes, apart from the following (due to software-specific dependencies):
- UPRN should be classified as Float.
- All attributes that have a Field Type of Date in the technical specification should be classified as Character with a length of 10.
After all changes have been made, click OK.
To create a map of the location of the AddressBase records, they need to be geocoded:
- Ensure the table of AddressBase records that you wish to geocode is open, then navigate to Table > Create Points.
- Select the table you wish to geocode from the Create Points for Table dropdown menu.
- Expand the Get X Coordinates from Column dropdown menu and select either X_Coordinate or Longitude.
- Expand the Get Y Coordinates from Column dropdown menu and select either Y_Coordinate or Latitude.
- Click on the Projection icon, then select the British Coordinate Systems option from the Category dropdown menu. Select the British National Grid [EPSG: 27700], or if you selected Longitude and Latitude in the steps above, select ETRS89 [EPSG: 4258].
- Click OK to close that window and OK again to close the next window.
- Finally, click Window > New Map Window to view the loaded geocoded points.

Loading CSV into QGIS

Note - These instructions are based on QGIS version 2.6.

Launch QGIS and click Settings > Options.
Select CRS from the left-hand menu and check that the Coordinate Reference System is set to British National Grid. Note - Check this is set for both Default CRS for new projects and the CRS for new layers sections. If these are not already set, click Select at the end of each section and type 27700 into the Filter Box to find and select British National Grid. Alternatively, if you intend to use Latitude and Longitude columns, select ETRS89 [EPSG: 4258].
Click OK.
Back in the QGIS UI, go to Layer and select Add Delimited Text Layer.
Select the CSV file and click Open.
Accept the default or create a new layer name for the dataset.
Ensure that the First record has field names box is ticked.
For Field Options, select Decimal separator is comma.
For Geometry Definition, select Point Coordinates.
You should now be able to select the X_Coordinate field for the X Field dropdown and the Y_Coordinate field for the Y Field dropdown if this was not done automatically. Alternatively, if you wish to use the Latitude and Longitude columns, the Longitude column needs to be inserted into the X_COORDINATE field, and the Latitude column needs to be inserted into the Y_COORDINATE field.
Click OK.

Loading CSV into a database

This section describes how to load AddressBase products into a few common databases.

Software dependencies:

ArcMap, ArcGIS Desktop and ArcGIS Server software do not support the BIGINT/NUMBER data type as an Object ID. Bear this in mind if the expectation is to use this data type directly with these ESRI products. An alternative method to facilitate using ESRI software is to store this data as a string and add a new Serial ID to act as the Object ID. If you are loading AddressBase data directly into a database, you may need to increase the column length to accommodate language characters such as '^'. Some databases treat this as an additional character and therefore, if you define the column length according to our specification, there is a chance that the load may fail. Please bear in mind such adjustments may be required depending on the database you use to load the data.

UPRN deletions:

If a UPRN is deleted and then reinserted, this does not compromise the integrity of the UPRN and its use as a primary key. If a delete is issued for a UPRN, this does not mean it will not reappear in subsequent supplies.

These are the reasons why this may happen:

The record has moved in location more than once, moving it out of your Area of Interest (AOI), hence the deletion, but then moved back into your AOI in the future. This would also occur if you altered your AOI.
A record has failed data validation upon a change being made. This can result, dependent on the change being made, in the record being deleted and then reintroduced when the error is fixed by the data supplier.

If a UPRN is deleted, it will not be reallocated to a different property and it therefore remains the unique identifier for a property.

Loading CSV into a PostGreSQL database

Note - These instructions are based on PostGreSQL version 1.12.3 and assume that you have set-up your database with the PostGIS spatial extension. It is recommended that you have basic understanding of database terminology before following this guide.

Check that there are no carriage returns (extra rows) at the end of the CSV output file as this will result in errors. To do this, open the CSV file and hit End on your keyboard. Your cursor should now be at the end of the last line, and not on any extra line below. If it is on the line below, hit Delete to remove the extra empty row.
Open the PGAdmin tool (this can be found in Windows Start Menu > PostGreSQL).
Either connect to an existing database or create a new database. It is recommended that the encoding is set to UTF-8.
Open the public schema (although in a production environment, it is advised to use a different schema) and create the tables using the following steps:
- Open the SQL query tool.
- This SQL file can be opened in a text editor, and the SQL scripts within it can be copied and pasted into the SQL query tool within PostGreSQL.
Once the table has been created, the data can be loaded into each table using the SQL COPY. Adding the CSV option as the first line contains a header record for each table. Please note that the examples below are for AddressBase, then AddressBase Plus and AddressBase Plus Islands, respectively. The path and filename may need to be changed to reflect your data set-up: COPY addressbase FROM 'C:/Address/AddressBase.csv' DELIMITER ', ' CSV HEADER; COPY addressbase_plus FROM 'C:/Address/AddressBase_Plus.csv' DELIMITER ', ' CSV HEADER; COPY addressbase_plus_islands FROM 'C:/Address/AddressBase_Plus_Islands.csv' DELIMITER ', ' CSV HEADER;

Once loaded, you may want to add Primary Keys to the data. However, these can only be added on columns where the data values are unique. Where there are no unique data values, an index may be added which will aid searching. The UPRN provides the only unique value in AddressBase and AddressBase Plus. Primary Keys are added using the following steps:

Right-click on the table name and select Properties.
Select the Constraints tab.
Click the + to add a new primary key.
Enter a name to call the key under the general tab (for example, Key1).
Under the definition tab, select UPRN or any other unique value from the dropdown under columns.

Click Save.

You can also index the data by following these steps:

Right-click on the table name and select Create > Index.
Under general, enter a name (for example, Idx1).
Under the definition tab > Columns, click the +.
Select the UPRN for example, or any other unique value.
Click Save.

Converting coordinates to geometry

A PostGIS extension is required to create geometries. The AddressBase products contain both British National Grid (BNG) and ETRS89 coordinates. The SQL below shows how to create a column for BNG, but it can be altered to utilise the ETRS89 data.

Add a geometry column called geom to make the data usable in a GIS: SELECT AddGeometryColumn ('public', 'addressbase_plus', 'geom', 27700, 'POINT', 2);
Load the data into your new geometry column: UPDATE public.addressbase_plus SET geom = ST_GeomFromText('POINT(' || x_coordinate || ' ' || y_coordinate || ') ', 27700); This sets the geom column in the table to equal the values from the X_coordinate and Y_coordinate columns, with the spatial reference defined as 27700.
Create a spatial index on the data using: CREATE INDEX idx_abp_geom ON public.addressbase_plus USING gist(geom); This adds the index name idx_abp_geom to the same table on the geom column.

Loading CSV into an Oracle database

Note - These instructions assume a basic knowledge of Oracle databases and SQLLDR (the package used to load the CSV files into the database). Other options are available for loading data into Oracle databases.

Using SQLLDR it is not necessary to merge all the AddressBase files into a single file, but it can load the data directly from the file provided as long as it has been unzipped first.

The following steps describe one method for loading a full supply of the data. Sections in italics denote where changes will need to be made to accommodate local file naming.

Copy the data files from the disk to an appropriate location. It is worth noting that the files will need to be unzipped and therefore you will need in the region of 43Gb of free space.
With all the files unzipped, the latter stages are easier if you create a list of all the CSV files to be loaded. This can be done using a batch file that writes all the files out to a text file: dir *.csv /b/s >filelisting.txt pause This file will form the basis for loading the control file in a later step.
Open the folder of your chosen product and you should see three files. Open the file ending createtable.sql in a text editor.
Within the provided SQL there are references to <TablespaceName>, which need to be changed to the tablespace that is being worked in. When these are changed, copy and paste the SQL into Oracle to create the tables.
Next, create a SQLLDR control file. An example of one of these files is Oracle AddressBase_Control.ctl, which is provided in the folder of the GitHub repository in Step 4 above. Open the SQLLDR control file for your chosen product in a text editor.
Within the file you will see lines referencing INFILE. Populate these INFILE lines with the file listing created in Step 3, with one INFLE command for each file. This tells the process to open each of the files and carry out the other tasks listed below it. Note – The last section of the control file creates the Geometry for the X and Y coordinate (British National Grid) if you want to create a Geometry for the Latitude and Longitude values, this will need to be created separately.
Once this file is created, it can be called from a .bat file to run it on the box that holds the database rather than a remote machine. If you wish to run it from a remote machine, contact your Oracle Administrator who will be able to advise on the best way to do this within your environment. The contents of the .bat file should be similar to the following: @sqlldr <username>/<password>@<service name> control= <name of ctl file created previously> Pause
Once the load has completed the relevant indexes need to be built. The SQL statements to create the indexes can be found in the same GitHub repository linked in Step 4 above. As before, you can copy and paste the SQL statements from a text editor into Oracle to create the indexes. The example table name provided may be different to yours, so check if this needs to be changed before use.

Loading CSV into Microsoft SQL Server

Note – There are many ways to load AddressBase products into Microsoft SQL Server; this is just one suggested method for guidance.

Open the SQL Server Management Studio (SSMS).
Right-click on the database you are loading into and select Properties.
Select Options on the left-hand side.
Expand the dropdown box for Recovery Model and select Bulk-logged. This minimises the logfile size, otherwise the default logging for Microsoft SQL Server can cause logfiles to grow over 20Gb and this can cause issues with loading.
Open the SQL Server Management Studio (SSMS) and right-click your database from the left-hand panel.
Navigate to Tasks and click Import Data. This will open the SQL Server Import and Export Wizard.
Click Next.
On the next screen, change your Data Source to Flat File Source.
Use the Browse button to navigate to your CSV file and select it. If you cannot see your files, ensure that the bottom right dropdown box has CSV files (*.csv) selected.
Click Open.
Check that the Text Qualifier is set to a double quote (“). This is to make sure that the quotations in the raw data supply are removed upon loading but that the data remains intact.
On the left-hand side of this screen, select Columns and check that the Column delimiter is set to Comma.
On the left-hand side of the screen, select Advanced.
For each column of data you are loading, you will need to specify a DataType. The Microsoft SQL Server loader defaults each column to a String. The correct Data Type for each column is given in the technical specification:
Once you have changed the Data Types for each column to match those given in the technical specification, click Next.
Check that your table is going to be imported into the correct database and click Next.
On this screen, you can edit the default table name that Microsoft SQL Server has chosen by clicking in the destination box. For example, for AddressBase Plus renaming to [dbo].[ADDRESSBASE_PLUS].
Select Edit Mappings in the bottom right-hand corner.
In the new window, you must remove the tick in the checkbox against the UPRN column, which needs to be the Primary Key of the table. Click OK once the Primary Key alterations have been completed.
Click Next. On this screen, you can check that the Source column and Destination columns are correct.
Click Next. A summary of your import will display. If you want to continue, click Finish.
A report will be generated as your data is imported. Success should appear at the top once complete.
You may need to right-click on your database and click Refresh to see your new table listed.

Setting Primary Keys

To create a Primary Key field, you can run an SQL statement, such as this example for AddressBase Plus below. Note - the columns you are creating these constraints on cannot be null or allowed to be null.

alter table dbo.ADDRESSBASE_PLUS add primary key ([UPRN]);

Creating the point geometry

You can also create point geometry using the X and Y coordinates or the Latitude and Longitude coordinate values. This is achieved by running the following SQL statement:

alter table dbo.ADDRESSBASE_PLUS
add geometry_column as geometry::Point([X_Coordinate],[Y_Coordinate], 27700);

Note – This is using British National Grid coordinates, with 27700 representing the spatial reference of the data. To use the Latitude and Longitude coordinate, the spatial reference should be set to 4258 for ETRS89.