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

This guide outlines a methodology for structuring and layering a single address label, providing suggested logic to build both the Delivery Point and Geographic Address. The logic in Delivery Point Address is applicable to AddressBase, AddressBase Plus and AddressBase Plus Islands. The logic in Geographic Address is only applicable to AddressBase Plus and AddressBase Plus Islands.

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 ComponentType

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 ComponentExample

DEPARTMENT_NAME

CUSTOMER SERVICE DEPARTMENT

ORGANISATION_NAME

JW SIMPSON LTD.

SUB_BUILDING_NAME

UNIT 3

BUILDING_NAME

THE OLD FORGE 7

BUILDING_NUMBER

7

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 ComponentData ContentFormatted 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 ComponentData contentFormatted 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.

An example of SQL logic to create a single-line Delivery Point Address is on our GitHub repository https://github.com/OrdnanceSurvey/AddressBase/tree/master/SQL, which should be used under the following considerations:

  • 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 ComponentType

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.

AttributeExample 1Example 2Example 3Example 4

PAO_START_NUMBER PAO_START_SUFFIX PAO_END_NUMBER PAO_END_SUFFIX

1

1

A

1

5

1

A 5 C

Rendered PAO range

1

1A

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.

AttributeExample 1Example 2Example 3Example 4

PAO (number string) PAO (text)

1

1A

1A

Rose Cottage

Rose Cottage

Rendered PAO (showing street name location)

1 <street>

1A <street>

Rose Cottage, 1A

<street>

Rose Cottage,

<street>

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 includedvsAdministrative 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 ComponentExample

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

1A

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 ComponentData contentFormatted 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 ComponentData contentFormatted 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’

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

Building a single-line, formatted address for a Geographic Address is slightly more complicated than for a Delivery Point Address due to the need to preformat the SAO and PAO number/range strings. However, once this is done, the process is largely the same as before: the calculated fields should be checked in the order shown previously in Constructing a single address label from the Geographic Address fields, 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 PAO number/range string and a street description. This is down to personal preference.

Example SQL logic to create a single-line Geographic Address can be found on our GitHub repository, which should be used under the following considerations:

  • 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:

  1. 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

  2. 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

  3. 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

  4. 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

  5. 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

  6. 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

  7. 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

  8. 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

  9. 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:

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

  2. 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.

Last updated