Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
This getting started guide provides instructions for using AddressBase Premium in different software applications. Users with limited technical knowledge will be able to follow this guide.
These instructions show you how to get started with AddressBase Premium and AddressBase Premium Islands.
AddressBase Premium data is supplied as comma-separated values (CSV), Geography Markup Language (GML) and GeoPackage (GKPG).
This guide shows you how to get started with AddressBase Premium and includes the following sections:
When you receive an order via hard media (DVD), the following files will be supplied if the supply is not a Managed Great Britain Set (MGBS):
Data
Doc
Order_Details.txt
Within the Data directory, data files will be found in their compressed format.
A text file called Label Information can be found within the Doc directory. This file is a replica of the information on the DVD should you need to reproduce or reprint this.
The Order_Details.txt provides information about the supply, including supply type, format, dates of order, currency and change. It also contains a list of all the zipped folders contained in the Data directory.
The following files will be supplied when you receive an order of a Managed Great Britain Set (MGBS) via hard media (DVD):
Data
Doc
Order_Details.txt
Within the Data directory, data files will be found in their compressed format.
A text file called Label Information can be found within the Doc directory. This file is a replica of the information on the DVD should you need to reproduce or reprint this.
The Order_Details.txt file provides information about the supply, including supply type, format, dates of order, currency and change. It also contains a list of all the zipped folders contained in the Data directory.
With a Secure File Transfer Protocol (SFTP) order, the same information is supplied as in DVD supply for an area of interest, but the file names will be slightly different, reflecting the SFTP order number.
The AddressBase Premium and AddressBase Premium Islands products are available as online downloads for customers who have signed up to the Public Sector Plan on the OS Data Hub. From October 2021, Premium Plan members will be able to download AddressBase Premium and AddressBase Premium Islands data from the OS Data Hub. Data can be downloaded in various formats.
The data is supplied as chunked files that cover your selected area. These files are named according to the convention shown in the following sub-sections.
When you open your data, you will see a series of zip folders:
For a MGBS supply of CSV and GML, you will see a single zip folder when you receive your download data. On opening the data link folder, you will see a series of separate unzipped files.
For example:
AddressBasePremium_FULL_2011-07-29_001_csv.zip
(full supply of CSV) or
AddressBasePremium_COU_2011-07-29_001_gml.zip
(COU supply of GML)
For a MGBS supply of GeoPackage, you will see a single zip folder when you receive your download data. On opening the data link folder, you will see a single unzipped file.
For example:
AddressBasePremium_FULL_2011-07-29_001_gpkg.zip
(full supply of GKPG)
When you receive your geo-chunked download data for CSV and GML, you will see a series of zipped folders on opening the data.
For example:
AddressBasePremium_FULL_2011-07-29_TQ2020_csv.zip
(full supply of CSV) or
AddressBasePremium_COU_2011-07-29_TQ2020_gml.zip
(COU supply of GML)
When you receive your geo-chunked download data for GKPG, you will see a single zipped folder on opening the data.
For example:
AddressBasePremium_FULL_2011-07-29_001_gpkg.zip
(full supply of GKPG)
The GML, GKPG and CSV data are supplied in a compressed form (ZIP). Some software can access these files directly, while other software will require it to be unzipped.
To unzip the zipped data files (.zip
extension), you can use an unzipping utility included with most modern operating systems. Alternatively, open-source zipping/unzipping software can be downloaded from the Internet such as 7-Zip.
When the files are unzipped, they are ready for use and will appear as follows:
AddressBasePremium_FULL_2020-02-11_001.csv
AddressBasePremium_ISL_FULL_2020-02-18_001.gml
AddressBasePremium_FULL_2020-02-18_001.gpkg
AddressBasePremium_2011-07-29_NC4040.csv
For GKPG supply, one GKPG will be supplied which will contain all the tiles:
AddressBasePremium_FULL_2020-02-18_001.gpkg
AddressBase Premium provides the most detailed view of an address and its life cycle for England, Wales and Scotland. It has approximately 40 million addresses as it records an address from creation through to retirement. All address records are provided with a Unique Property Reference Number (UPRN).
This product is updated every six weeks
There are over 100 million cross references which include references to VOA data and products such as OS MasterMap Topography Layer and OS Highways Layer are also included.
The product contains Local Authority, Ordnance Survey and Royal Mail addresses. This includes alternative addresses for current records where available, indicating variations on the official addresses and/or addresses in different languages (Welsh or Gaelic); as well as including provisional addresses (proposed planning developments), and historic information (demolished properties) where available. Other addresses known as Objects Without a Postal Address (OWPAs) are also included in AddressBase Premium, these include places of worship, community centres and utilities.
The AddressBase Premium dataset contains Local Authority, Ordnance Survey and Royal Mail addresses, each uniquely referenced by the UPRN.
Property level coordinates within AddressBase Premium allow you to conduct analysis at the level of individual addresses and spot patterns hidden in your own data.
With UPRNs being assigned as soon as planning permission is granted, with AddressBase Premium you'll have all the information you need to shape the way you plan, operate and communicate with your audience.
Each address is referenced by the Unique Property Reference Number (UPRN), a persistent identifier for each address allowing you to manage addresses and making your processes more efficient.
Access: Download
Data theme: Address
Data structure: Vector - Points
Coverage: Great Britain
Scale: 1:1 250 to 1:10 000
Format: CSV, GeoPackage, GML 3.2.1
Ordering area: All of Great Britain or customisable area (5km2 tiles or user defined polygon)
OS Data Hub plan: Public Sector Plan, Premium Plan, Energy & Infrastructure Plan
Access to this product is free for PSGA members. Find out if you are a PSGA member or try out a sample of AddressBase Premium data by accessing the product page here with links to all of the relevant resources. Alternatively, you can try out the full product by applying for a Data Exploration license.
AddressBase Premium is an addressing gazetteer offering full property life cycle information that can be used within GIS and database systems. For details of Ordnance Survey’s licensed partners, who can incorporate the AddressBase products into their systems, please see the systems/software page on the Ordnance Survey website.
Ordnance Survey does not recommend specific suppliers or software products as the most appropriate system will depend on many factors, for example, the amount of data being taken, resources available within the organisation, the existing and planned information technology infrastructure, and the applications that AddressBase products can be used for.
However, as a minimum, the following elements will be required in any system:
A means of reading the data, either in its native format, or by translating it into a file format or for storage in a database.
A means of storing and distributing the data, perhaps in a database or through a web-based service.
A way of visualising and querying the data, typically a GIS.
You are advised to copy the supplied data to a backup medium.
For reading purposes, it is recommended to store the data on a single hard disc. This will speed up the ability of your computer to read the data.
The table below lists the unzipped file sizes for the GB full supply of the two products.
Product name | CSV | GML | GKPG |
---|---|---|---|
This section provides step-by-step instructions on how to load the Geography Markup Language (GML) format of AddressBase Premium products into FME and a database.
GML is an XML dialect which can be used to model geographic features. It was designed by the Open Geospatial Consortium (OGC) as a means for people to share information regardless of the applications or technology that they use.
In the first instance, GML was used to overcome the differences between different GIS applications by providing a neutral file format as an alternative to proprietary formats. Because it is independent of applications, it can also be moved between databases or other types of application, which allows a wider application than just GIS data transfer.
Several organisations provide a loader which will translate AddressBase Premium from GML and insert the data into a database or a GIS. Due to the relational nature of AddressBase Premium, GML will not load straight into most GIS applications, meaning an external translator would be helpful to most users. If you would like to load AddressBase Premium in GML format into a GIS, please contact your vendor for more details.
For more information on Ordnance Survey Partners who provide GML loaders, please visit the .
AddressBase Premium and AddressBase Premium Islands are complex relational datasets that are used by a variety of customers who use a variety of methods and software to manage the data. Some of the software solutions take a considerable length of time to load and manage the data. A change-only update (COU) is a simple and effective way to keep data holdings up to date without spending considerable time loading and managing a full supply every time the data is refreshed.
A COU means you will only be supplied with the features which have changed since your last supply. The following sub-sections provide guidance on how to manage a COU supply of AddressBase Premium data.
Note - If you receive a tile supply, you will receive Change Chunks. This means if a record within your tile has changed, then all of the records in that tile will be provided to you as inserts, and no updates or deletes will be issued. This is not applicable for AddressBase Premium Islands as a tile supply is not available for that product.
At a high-level, there are three types of change found within a COU:
Deletes (CHANGE_TYPE ‘D’) are objects that have ceased to exist in your area of interest (AOI) since the last product refresh.
Inserts (CHANGE_TYPE ‘I’) are objects that have been newly inserted into your AOI since the last product refresh.
Updates (CHANGE_TYPE ‘U’) are objects that have been updated in your AOI since the last product refresh.
The diagram below outlines how to implement the AddressBase Premium COU within a database. It also shows the necessary primary keys needed to implement the COU for each relational table.
Before a COU is applied, there may be a business requirement to archive existing address records. The diagram below outlines how to implement the AddressBase Premium COU within a database, shows the necessary primary keys needed to implement the COU for each relational table, and how to archive existing records.
Within the Basic Land and Property Unit (BLPU) table, there will not be any records with the same UPRN. This can be tested by checking the number of records that have the same UPRN. The following SQL code would notify you of any duplicates:
This query should return 0 rows, and this confirms there are no duplicates. As there are no duplicate records, the UPRN can be used to apply the COU. Once confirmed, the following steps can be taken to apply the COU (without archiving):
Initially delete the existing records that will be updated and delete
Insert the new updated records and the newly inserted records
Some of the COU records that are change type ‘U’ (updates) may change the Logical Status Code from ‘1’ to ‘8’, meaning that this address has become ‘Historical’. This means that the BLPU table intrinsically archives historical records.
Where there is a business requirement to keep the records that are being updated and deleted in a separate archive table, the following SQL will create an Archive Table and populate it with records that are being Updated and Deleted from the live BLPU table.
The following command creates an archive table of the records that are being updated and deleted from the existing BLPU table:
If this table already exists, you can simply use INSERT INTO
rather than CREATE TABLE
The following command then deletes the records from the existing table which are either updates or deletions:
The following command then inserts the new insert records and the new updated records into the live BLPU table:
Because there is a one-to-many relationship between the BLPU table and the Classification table, there can be records in the Classification table that share a UPRN. To apply COU to the correct record, users should use the Class_Key to ensure that the correct classification record is updated.
The table below provides examples of using the Class_Key to apply a COU to one of two classification records that share a UPRN in a Classification table.
The example in classification code table above illustrates a scenario when a user would need to choose between two classification records that have the same UPRN. In this case, the Class_Key has been used to apply the COU to Record 2.
To achieve this outcome (without archiving the ‘old’ Record 2), we can use the following SQL commands to apply the COU:
Initially delete the existing records that are being updated and deleted:
Insert the new update records and the new insert records:
One thing you may want to consider is keeping an archive of the updated and deleted classification records. For example, this might be useful to understand when an address has changed use from residential to commercial.
To achieve this outcome for change types ‘U’ (updates) or ‘D’ (deletes) (with archiving), we can use the following SQL commands to apply the COU:
The following command creates an archive table of the records that are being updated and deleted from the existing Classification table. If this table already exists, you can simply use INSERT INTO rather than CREATE TABLE:
The following command then deletes the records from the existing table that are either updates or deletions:
The following command then inserts the new insert records and the new updated records into the Classification table:
The following table shows classification and archive record details:
When the updated or deleted records are moved into an archive table, the end date may not always be populated, as seen in Table 4. If this is the case, users may wish to consider adding an end_date (which could be based on the epoch date that it was archived) as shown in Table 5. Adding an end date to an updated or deleted record will enable querying for a particular timeframe.
The following table shows classification and archive record with an end date details:
The numerous one-to-many relationships between the BLPU table and the Organisation table mean there can be records in the Organisation table that share a UPRN. To apply COU to the correct record, we should use the Org_Key to ensure that the correct classification record is updated.
To apply the COU to the Organisation table (without archiving), the following code can be used:
Initially delete the existing records that will be updated and deleted:
Insert the new updated records and the newly inserted records:
As with the Classification table, the changes in Organisation name may be useful to keep as archives as doing so will allow a business to find previous organisations and understand when name changes were made.
To apply the COU to the Organisation table (with archiving), the following code can be used:
The following command creates an archive table of the records that are being updated and deleted from the existing Organisation table.
If this table already exists, you can simply use INSERT INTO
rather than CREATE TABLE
:
The following command then deletes the records from the existing table that are either updates or deletions:
The following command then inserts the new insert records and the new updated records into the Organisation table:
Within the Delivery Point Address table, there will not be any records with the same Unique Delivery Point Reference Number (UDPRN). This can be tested by checking the number of records that have the same UDPRN. The following SQL code would notify you of any duplicates:
This query should return 0 rows, and this confirms that there are no duplicates. As there are no duplicate records, we can therefore use the UDPRN to apply the COU.
To apply the COU to the Delivery Point Address table (without archiving), the following code can be used:
Initially delete the existing records that will be updated and deleted:
Insert the new updated records and the new inserted records:
The Delivery Point Address table does not have the ability to hold historical records as it is the current view of the Royal Mail Delivery Point Address File (PAF). Therefore, in order to capture the historical records, you will need to create an archive table that is populated when records are either deleted or updated. The following code will create the archive records:
To apply the COU to the Delivery Point Address table (with archiving), the following code can be used:
The following command creates an archive table of the records that are being updated and deleted from the existing Delivery Point Address table.
If this table already exists, you can simply use INSERT INTO
rather than CREATE TABLE
:
The following command then deletes the records from the existing table that are either updates or deletions:
The following command then inserts the new insert records and the new updated records into the Delivery Point Address table:
The numerous one-to-many relationships between the BLPU table and the Land and Property Identifier (LPI) table mean there can be records in the LPI table that share a UPRN. To apply the COU to the correct record, we should use the LPI_Key to ensure that the correct classification record is updated.
To apply the COU to the LPI table (without archiving), the following code can be used:
Initially delete the existing records that will be updated and deleted:
Insert the new updated records and the new inserted records:
As with the BLPU table, some of the COU records that are change type ‘U’ (updates) may change the Logical Status Code from ‘1’ to ‘8’, meaning that this address has become ‘historical’. This means that the LPI table intrinsically archives the historical record.
Where there is a business requirement to keep the records that are being updated and deleted in a separate archive table, the following SQL will create an archive table and populate it with records that are being updated and deleted from the live LPI table.
To apply the COU to the LPI table (with archiving), the following code can be used:
The following command creates an archive table of the records that are being updated and deleted from the existing LPI table.
If this table already exists, you can simply use INSERT INTO
rather than CREATE TABLE
:
The following command then deletes the records from the existing table which are either updates or deletions:
The following command then inserts the new insert records and the new updated records into the LPI table:
The following table shows an original LPI record next to a COU record. In this example, the record is being made historical (logical status code: 8) and therefore has a populated end date attribute.
Within the Street table, there will not be any records with the same Unique Street Reference Number (USRN). This can be tested by checking the number of records that have the same USRN. The following SQL code would notify you of any duplicates:
This query should return 0 rows, and this confirms there are no duplicates. As there are no duplicate records, we can use the USRN to apply the COU.
To apply the COU to the Street table (without archiving), the following code can be used:
Initially delete the existing records that will be updated and deleted:
Insert the new updated records and the new inserted records:
The Street table does not have the ability to hold historical records as it does not have a Logical Status Code attribute. Therefore, to capture the historical records, you will need to create an archive table that is populated when records are either deleted or updated.
To apply the COU to the Street table (with archiving), the following code can be used:
The following command creates an archive table of the records that are being updated and deleted from the existing Street table.
If this table already exists, you can simply use INSERT INTO
rather than CREATE TABLE
:
The following command then deletes the records from the existing table that are either updates or deletions:
#The following command then inserts the new insert records and the new updated records into the Street table:
Within the Street Descriptor table, there will not be any records with the same USRN and the same language. This is called a compound key, rather than having a single column as a Primary Key. This can be tested by checking the number of records that have the same USRN. The following SQL code will notify you of any duplicates:
This query should return 0 rows, and this confirms there are no duplicates using the compound key. As there are no duplicate records, we can therefore use the USRN and LANGUAGE to apply the COU.
To apply the COU to the LPI table (without archiving), the following code can be used:
Initially delete the existing records that will be updated and deleted:
Insert the new updated records and the new inserted records:
The Street Descriptor table does not have the ability to hold historical records as it does not have a Logical Status Code attribute. Therefore, to capture the historical records, you will need to create an archive table that is populated when records are either deleted or updated.
To apply the COU to the Street Descriptor table (with archiving), the following code can be used:
The following command creates an archive table of the records that are being updated and deleted from the existing Street table.
If this table already exists, you can simply use INSERT INTO
rather than CREATE TABLE
:
The following command then deletes the records from the existing table that are either updates or deletions:
The following command then inserts the new insert records and the new updated records into the Street table:
Within the Cross Reference table, there will not be any records with the same XREF_KEY. This can be tested by checking the number of records that have the same XREF_KEY. The following SQL code will notify you of any duplicates:
The query above should return 0 rows and therefore confirms that there are no duplicates. As there are no duplicates, we can therefore use the XREF_KEY to apply the COU.
To apply the COU to the Cross Reference Table (without archiving), the following code can be used:
Initially delete the existing records that will be updated and deleted:
Insert the new records and the updated records:
The Cross Reference table does not have the ability to hold historical records as it does not have a logical status code attribute. Therefore, to capture the historical records, you will need to create an archive table which is populated when records are either deleted or updated.
To apply the COU to the Cross Reference table (with archiving), the following code can be used:
The following command creates an archive table of records which are being updated and deleted from the existing Cross Reference table.
If this table already exists, you can simply use INSERT INTO
rather than CREATE TABLE
:
The following command then deletes the records from the existing table that are either updates or deletes:
The following command then inserts the new insert records and the updated records:
The AddressBase Premium products contain a variety of data fields which allow a user to construct, for a given addressable object, different forms of an address dependent on how the address is to be used.
There are two types of address contained in the AddressBase products:
Delivery Point Address
Geographic Address
These two address types come from different sources and are matched together by GeoPlace.
The Delivery Point Address is sourced from Royal Mail’s Postcode Address File (PAF), which is a non- geocoded list of addresses. These addresses are used primarily as a ‘mailing list’ for postal purposes.
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 aid, 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.
The AddressBase Premium data model accommodates both the Delivery Point Address and the Geographic Address by linking them using the unique property reference number (UPRN) as the key.
It is important to note the cardinality differences that the Geographic and Delivery Point Address components have with the Basic Land and Property Unit (BLPU):
The relationship between the Delivery Point Address and the BLPU is 0..1 – 1.
This means that the Delivery Point Address is an optional component, so a Delivery Point Address will only be created when it has been matched to the Geographic Address. Moreover, only one Delivery Point Address can be matched to a BLPU.
The relationship between the Land and Property Identifier (LPI) and the BLPU is 1..* – 1.
This means that the LPI component is mandatory; therefore, at least one LPI must exist for each BLPU. Moreover, there can be more than one LPI linked to a single BLPU.
Together, these differences mean that there are more Geographic Addresses in the product than there are Delivery Point Addresses, because:
Not every BLPU has a Delivery Point (postal) Address, only those that have been matched to the Royal Mail PAF database.
A single BLPU can have only one Delivery Point Address.
A single BLPU can have more than one Geographic Address (because alternative and historical addresses are available in AddressBase Premium).
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: single line and multi-line. The simplest label 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), for example:
ROSE COTTAGE, 5 MAIN STREET, ADDRESSVILLE, LONDON, SE99 9EX
The second type of formatted address is a multi-line address label. These labels are most often used on envelopes or at the tops of letters, where different parts of an address are separated onto different lines, for example:
ROSE COTTAGE 5 MAIN STREET ADDRESSVILLE LONDON SE99 9EX
The following sections outline a methodology for structuring and layering a single address label using AddressBase Premium. The rules outlined 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.
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 listed in Table 7 can be used to build a Delivery Point Address label.
The following table details the Delivery Point Address components.
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 (listed in Table 7). The following examples will use the English version of these attributes.
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 illustrates how these fields should be ordered in a single address label:
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:
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, as shown in the following example:
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 the tables above, 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.
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). If there is no thoroughfare information, the building number should appear on the same line as the first locality line.
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 (or on the first locality line if no thoroughfare is present).
In most other cases, the building name, if present, should appear on a separate line above the thoroughfare name or dependent thoroughfare or locality line if no thoroughfare is present.
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.
The structure of a Geographic Address is based on the British Standard BS7666 and is split into a number of 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 products, the core property-level address information is stored within the Primary Addressable Object (PAO) and Secondary Addressable Object (SAO) fields of the LPI table. The additional attribution required to build a full address label is maintained in the BLPU (postcode_locator), ORGANISATION (organisation) and STREET_DESCRIPTOR (street_description, locality_name, town_name, administrative_area) tables.
To construct a single address label based purely on the BS7666 address fields, the following attributes listed in the table below should be used to build a Geographic Address label.
The following table details the Geographic Address components.
*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 build the address using the alternate language for SAO_TEXT, PAO_TEXT and Street Descriptor entries. This can be achieved by filtering on the language field of the LPI and Street Descriptor tables. The same order as above would be applicable.
The LPI table includes the PAO and SAO fields. However, in order to obtain the rest of the address, it is necessary to join the LPI table to the Street Descriptor table to pick up the street name, locality and town information (using the USRN as the key), and also to the Organisation and BLPU tables (using the UPRN as the key) to pick up the organisation names and postcodes, respectively.
The diagram below shows the links that need to be made in order to build a full Geographic Address from the different BS7666 components in AddressBase Premium.
Using the LPI table as a starting point, the remaining address components can be picked up using table joins to the other tables on UPRNs and USRNs. Note that there can be more than one LPI for each UPRN, so if only one address is required per BLPU, the LPI with logical_status = 1 (approved) should be selected (there can be only one approved LPI per BLPU).
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:
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.
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, as shown in the following table:
For primary addressable objects (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.
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 is often the case. The following table shows an example where the administrative area name (in this case, BURY) has been included and excluded from a single-line address:
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 illustrates how they should be ordered in a single address label.
The table below details the Geographic Address formatting:
*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.
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.
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 pre-format the SAO and PAO number/range strings and join tables together. 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 the table above, 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.
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 want no duplicate UPRNs to be returned an additional DISTINCT line needs to read DISTINCT(l.UPRN).
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. 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 ROSE COTTAGE, MAIN STREET PAO_text and PAO number or range 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 line where there is no PAO_text value). SAO_text value only, with PAO_text value only THE ANNEXE, ROSE COURT,
MAIN STREET SAO_text value only, with PAO number/range only 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 1A ROSE COURT, MAIN STREET SAO number/range value only, and PAO number/range value only 1-3, 11A MAIN STREET SAO number/range value only, and both PAO_text and PAO number/range values 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 THE ANNEXE, ROSE COTTAGE, MAIN STREET SAO_text and SAO number/range and PAO_text and PAO number/range 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 [first part of address, formatted as described above] MAIN STREET,
HIGHFIELD,
SOUTHAMPTON Town Name only [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
It's possible to create mailing lists using the AddressBase Premium and AddressBase Premium Islands products (you can also create them using AddressBase Plus and AddressBase Plus Islands). Given that the AddressBase Premium products contain two different types of address, a decision needs to be made on 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, 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.
When building your query to extract a mailing list, it is important that you consider filtering your results based on the address status and type. The status of an address is often something that needs to be considered when working with address data. Questions need to be answered before AddressBase Premium can be used effectively, such as “Is the addressable object in planning, being constructed, current, demolished or accurately positioned?”.
AddressBase Premium is a rich addressing dataset that contains a wealth of other attributes that could be used in conjunction with address labels. For example:
Classification can be used to target certain types of property.
OS MasterMap Topography TOID cross references can be used to link address labels to Topographic objects and viewed in a GIS for Great Britain (AddressBase Premium Islands does not has OS MasterMap Topography TOID cross references).
The AddressBase Premium CSV and AddressBase Premium Islands CSV are provided with records for various tables incorporated into a single CSV. Depending on the size of the area of interest (AOI) or if you require a full supply of GB or Islands data, there may be multiple CSV files supplied. These CSV files need to be split into individual records and tables.
There are multiple methods for splitting AddressBase Premium CSV files by the record identifiers. The following sub-sections step you through using either Gawk or Python for splitting the data and appending the header file.
Both methods require the that are available on the page.
This section provides step-by-step instructions on how to load the CSV format of AddressBase Premium products into commonly used GIS software, including ArcGIS Pro, ArcGIS Desktop, MapInfo, QGIS and CadCorp SIS Desktop.
It is assumed that you will have followed the steps in before you attempt to load the data. If this pre-processing is not carried out, there may be errors with loading.
This section provides step-by-step instructions on how to load the CSV format of AddressBase Premium products into some commonly used databases, including PostgreSQL, Oracle and Microsoft SQL Server databases.
It should be noted that 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 the load may fail. Please bear in mind such adjustments may be required depending on the database you use to load the data.
It is important to note that Primary Keys on all tables (for example, UPRN on the BLPU table) are valid upon a data load. If a Delete is issued for a Primary Key, this doesn’t mean that Primary Key will not reappear in subsequent supplies.
There are a number of reasons this may happen:
The record has moved in location more than once, moving it out of your AOI (therefore, the record is deleted) but then 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 unique property reference number (UPRN) is deleted, it will not be reallocated to a different property, and it therefore remains the unique identifier for a property.
This section provides step-by-step instructions on how to access the GKPG format of AddressBase Premium products via commonly used GIS software, including ArcGIS Pro, ArcGIS Desktop, and QGIS.
GKPG (.gpkg
) is an open, non-proprietary, platform-independent and standards-based data format for geographic information systems (GIS), as defined by the Open Geospatial Consortium (OGC). It is designed to be a lightweight format that can contain large amounts of varied and complex data in a single, easy to distribute and ready to use file. GKPG is natively supported by numerous software applications.
The relational nature of AddressBase Premium has meant that loading GKPG into certain GIS is not possible at the time of this document's release.
The following sub-section provides step-by-step instructions on how to load the AddressBase Premium GKPG into PostgreSQL using GDAL / Command Prompt.
Classification | Record 1 | Record 2 | Classification | Updated record | Record 2 | Classification | COU record |
---|
Classification | Archive record |
---|
Classification | Archive record |
---|
LPI | Record | COU Record |
---|
Delivery Point Address component | Type |
---|
Delivery Point Address component | Example |
---|
Examples of SQL logic to create a single-line Delivery Point Address are on our , which incorporates the following elements:
For a full description of PAOs and SAOs, and the complete set of AddressBase fields, please refer to the relevant
Table | Geographic Address Component |
---|
Attribute | Example 1 | Example 2 | Example 3 | Example 4 |
---|
Attribute | Example 1 | Example 2 | Example 3 | Example 4 |
---|
Geographic Address Component | Example |
---|
Delivery Point Address Component | Data content | Formatted output |
---|
Delivery Point Address Component | Data content | Formatted output |
---|
Example SQL logic to create a single-line Geographic Address can be found on our , which incorporates the following elements:
The table below offers guidance on what status filters should be considered. Please see the on our website for more information about each of these attributes.
Status attributes | Table | Use | Values |
---|
Note - When using CSV data in ArcGIS Desktop, it is necessary to split out the individual record types from the original single CSV file and to append column headings. Before following these instructions, ensure the splitting and headings have already been prepared as described in .
You need to create the following joins / relates between the tables, as stated in the:
Note - When using CSV data in MapInfo, it is not a critical requirement to have column headings. However, for ease of use, we recommend using the headings supplied by Ordnance Survey. Instructions on how to append the Header files can be found in .
Here, you can change the Type and Width of each attribute to match the ones stated in the .
As AddressBase Premium is made up of many record types, we need to make joins to view all the available data. The joins you need to make are given in the , but for reference:
Click the three dots button next to the file name box and locate the CSV file that was created in , named ID21_BLPU_Records
. Do not select any files with Record
at the start of their name. Select the CSV file and click Open.
Click the three dots button next to the file name box and locate the CSV file that was created in named ID23_ XREF_Records
. Do not select any files with Record at the start of their name. Select the CSV file and click Open.
At this stage, it is possible to load the spatial tables (BLPU and Streets) into CadCorp. You can join these tables together within your chosen database to then add all data into CadCorp. Please refer to the to gain a better understanding of the relationships between AddressBase Premium tables.
Following on from the instructions in , use the following instructions to load AddressBase Premium into CadCorp SIS Desktop via a database:
Prepare the text files as described in .
Download the SQL file in the .
Click the edit button .
To help performance when querying across multiple tables, a Foreign Key may be added. A list of the Foreign Keys with AddressBase Premium can be found in the section of the . However, as with a Primary Key, only unique data columns can be used.
Click the edit button .
Go to the .
Note - The following instructions assume that you have basic knowledge of Microsoft SQL Server, and that the CSV data is already prepared as described in .
Your CSV file should already have a header row from . Ensure that Column names in the first data row is ticked.
For each column of data that you are loading, you will need to specify a DataType. The Microsoft SQL Server loader defaults each column to a String. The correct Data Types for each column are given in section of the .
In the new window, you must remove the tick in the checkbox against the column which needs to be the Primary Key of the table. The Primary Keys for each table can be found in the in section of the .
AddressBase Premium
40 Gb
186 Gb
28 Gb
AddressBase Premium Islands
1 Gb
4 Gb
0.8 Gb
Record identifier | 32 | 32 | Record identifier | 32 | 32 | Record identifier | 32 |
Change type | I | I | Change type | U | I | Change type | U |
Pro order | 922371 | 922372 | Pro order | 922500 | 922372 | Pro order | 922500 |
UPRN | 100062645004 | 100062645004 | UPRN | 100062645004 | 100062645004 | UPRN | 100062645004 |
Class key | 1715C000002050 | 1715C802457028 | Class key | 1715C000002881 | 1715C802457028 | Class key | 1715C000002881 |
Classification code | U | CS | Classification code | CR08 | CS | Classification code | CR08 |
Class scheme | AddressBase Premium classification scheme | VOA Primary Description | Class scheme | AddressBase Premium classification scheme | VOA Primary Description | Class scheme | AddressBase Premium classification scheme |
Scheme version | 1.0.0 | 1.0.0 | Scheme version | 1.0.0 | 1.0.0 | Scheme version | 1.0.0 |
Start date | 2011-12-01 | 2010-03-16 | Start date | 2011-12-01 | 2010-01-16 | Start date | 2011-12-01 |
End date | N/A | N/A | End date | N/A | N/A | End date | N/A |
Last update | 2011-12-01 | 2010-08-12 | Last update date | 2013-05-04 | 2010-08-12 | Last update | 2013-05-04 |
Entry date | 2011-12-01 | 2010-03-16 | Entry date | 2011-12-01 | 2010-03-16 | Entry date | 2011-12-01 |
Record identifier | 32 |
Change type | I |
Pro order | 706838 |
UPRN | 116000665 |
Class key | 9055C000081107 |
Classification code | CL10RE |
Class scheme | AddressBase Premium classification scheme |
Scheme version | 1.0.0 |
Start date | 2011-12-01 |
End date | N/A |
Last update date | 2011-12-01 |
Entry date | 2011-12-01 |
Record identifier | 32 |
Change type | I |
Pro order | 706838 |
UPRN | 116000665 |
Class key | 9055C000081107 |
Classification code | CL10RE |
Class scheme | AddressBase Premium classification scheme |
Scheme version | 1.0.0 |
Start date | 2011-12-01 |
End date | 2013-05-04 |
Last update date | 2011-12-01 |
Entry date | 2011-12-01 |
Record identifier | 24 | 24 |
Change type | I | U |
Pro order | 478857 | 478857 |
UPRN | 100000527208 | 100000527208 |
LPI key | 4520L000005174 | 4520L000005174 |
Language | ENG | ENG |
Logical status | 1 | 8 |
Start date | ‘2001-03-23’ | ‘2001-03-23’ |
End date | ‘2013-04-24’ |
Last update date | ‘2010-05-21’ | ‘2013-04-24’ |
Entry date | ‘2001-03-23’ | ‘2001-03-23’ |
SAO start number |
SAO start suffix |
SAO end number |
SAO end suffix |
SAO text |
PAO start number |
PAO start suffix |
PAO end number |
PAO end suffix |
PAO text | ‘SITE OF FORMER MISER NETHAULERS’ | ‘FORMER SITE OF MISER NETHAULERS’ |
USRN | 36815950 | 36815950 |
USRN match indicator | 1 | 1 |
Area name |
Level |
Official flag |
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 |
DEPARTMENT_NAME | CUSTOMER SERVICE DEPARTMENT |
ORGANISATION_NAME | JW SIMPSON LTD. |
SUB_BUILDING_NAME | UNIT 3 |
BUILDING_NAME | THE OLD FORGE |
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 |
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 |
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 |
Organisation | ORGANISATION |
LPI | SAO_TEXT |
LPI | SAO_START_NUMBER |
LPI | SAO_START_SUFFIX |
LPI | SAO_END_NUMBER |
LPI | SAO_END_SUFFIX |
LPI | PAO_TEXT |
LPI | PAO_START_NUMBER |
LPI | PAO_START_SUFFIX |
LPI | PAO_END_NUMBER |
LPI | PAO_END_SUFFIX |
Street Descriptor | STREET_DESCRIPTION |
Street Descriptor | LOCALITY |
Street Descriptor | TOWN_NAME |
Street Descriptor | ADMINISTRATIVE_AREA* |
BLPU | POSTCODE_LOCATOR |
PAO_START_NUMBER | 1 | 1 | 1 | 1 |
PAO_START_SUFFIX | A | A |
PAO_END_NUMBER | 5 | 5 |
PAO_END_SUFFIX | C |
Rendered PAO range | 1 | 1A | 1-5 | 1A-5C |
PAO (number string) | 1 | 1A | 1A |
PAO (text) | Rose Cottage | Rose Cottage |
Rendered PAO (showing street name location) | 1 <street> | 1A <street> | Rose Cottage, 1A <street> | Rose Cottage, <street> |
Administrative area not included | 34, CROW LANE, RAMSBOTTOM, BL0 9BR |
Administrative area included (BURY) | 34, CROW LANE, RAMSBOTTOM, BURY, BL0 9BR |
ORGANISATION | JW SIMPSON LTD |
SAO_TEXT | THE ANNEXE |
SAO (number / range string)* | 1A |
PAO_TEXT | THE OLD MILL |
PAO (number / range string)* | 7–9 |
STREET_DESCRIPTION | MAIN STREET |
LOCALITY | HOOK |
TOWN_NAME | WARSASH |
ADMINISTRATIVE_AREA | SOUTHAMPTON |
POSTCODE_LOCATOR | SO99 9ZZ |
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 |
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_NAME | null |
TOWN_NAME | ‘HORSHAM’ | HORSHAM |
ADMINISTRATIVE_AREA | ‘HORSHAM’ | * Duplicate name omitted |
POSTCODE_LOCATOR | ‘RH12 1EQ’ | ‘RH12 1EQ’ |
LOGICAL_STATUS | BLPU | Describes where a land or property unit is in its lifecycle. | 1 = Approved 6 = Provisional 8 = Historical |
LOGICAL_STATUS | LPI | Describes where an address is in its lifecycle. | 1 = Approved 3 = Alternative 6 = Provisional 8 = Historical |
BLPU_STATE_CO DE (optional) | BLPU | Informs the user what physical state the land or property is in (for example, ‘under construction’, ‘in use’, ‘demolished’). | 1 = Under construction 2 = In use 2 = Unoccupied 4 = No longer existing 6 = Planning permission granted Null= Unknown or N/A |
RPC_CODE | BLPU | To ascertain how accurate the coordinate is. Use in conjunction with the postcode_locator field to understand the accuracy of the address’ position. | 1 = Visual centre 2 = General internal point 3 = SW corner of 100m grid ref 4 = Start of referenced street 5 = Postcode unit point 9 = Centre of Local Authority area |
ADDRESSBASE_ POSTAL | BLPU | This field can be used to limit your records based on whether they are capable of receiving mail or not. | D = A record which is linked to PAF C = A record which is postal and has a parent linked to PAF L = A record identified as postal via Local Authority information N = Not a postal address |
LANGUAGE | LPI STREET_DESCRIPTOR | This information can be used to limit your records based on the language. | ENG = English CYM = Welsh GAE = Gaelic |
This technical specification provides detailed technical information about AddressBase Premium. It is targeted at technical users and software developers.
AddressBase Premium provides the most detailed view of an address and its life cycle for England, Wales and Scotland. It has more records than AddressBase Plus as it provides all information relating to an address or property from its creation to retirement.
The product contains Local Authority, Ordnance Survey and Royal Mail addresses. This includes alternative addresses for current records where available, indicating variations on the official addresses; and provisional addresses (proposed planning developments), and historic information (no longer existing, for example demolished properties) where available. OWPA (Objects Without a Postal Address) and cross references to VOA (Valuation Office Agency) data and products such as OS MasterMap Topography Layer are also included.
This technical specification includes the following sections:
All AddressBase products include the Unique Property Reference Number (UPRN) and are based on same coordinate reference systems.
Please see the General AddressBase information section for additional information that applies across all AddressBase products.
This section describes the feature types (one for CSV and GeoPackage, and two for GML) which make up the AddressBase Premium product, giving the following information about each attribute.
The name of the attribute and what it is describing.
A condition associated with this attribute (optional).
The nature of the attribute, for example, a numeric value or a code list value.
Describes how many times this element is expected to be populated in the data. An attribute may be optional or mandatory within the product. These are denoted by:
‘1’ – there must be a value
‘0..1’ – population is optional but a maximum of one attribute will be returned These values may be used in combination.
The primary supply mechanism of AddressBase Premium data is referred to as non-geographic chunks. This is a way of dividing up the data into chunks that are supplied in separate volumes, which have a fixed maximum amount of records. The supply is not supplied with any reference to the geographic position of records.
Public Sector Geospatial Agreement (PSGA) customers are able to order geographic chunks (5km tiles) as well as non-geographic chunks, although geographic chunks are not considered the main form of supply.
All customers are also able to take a complete supply (referred to as a Managed Great Britain Set: MGBS) or an area of interest (AOI) as a full supply or change-only update (COU) supply.
The filename for non-geographic chunks is constructed as follows:
ProductName_supply_ccyy-mm-dd_vvv.format:
ProductName: AddressBasePremium
supply: FULL
or COU
ccyy-mm-dd: the date the file was generated
vvv: the volume number of the file
format: the format of the files, for example, csv
, gml
or gpkg
For example:
AddressBasePremium_FULL_2013-05-28_001.gml
(GML full supply)
AddressBasePremium_FULL_2013-05-28_001.gpkg
(GeoPackage full supply)
AddressBasePremium_COU_2013-05-28_001.csv
(CSV COU supply)
A file size limit might be imposed by the file system to which the file is written.
If the data has been provided in a ZIP file, the filename is constructed as follows:
productName_supply_ccyy-mm-dd_vvv_format.zip
For example:
AddressBasePremium_FULL_2013-05-28_001_gml.zip
(GML full supply zipped)
If you receive your data as geographic chunks (PSGA customers only), the filename for geographic chunks (PSGA customers only) is constructed as follows:
ngxxyy.format
ngxxyy: The four-digit grid reference belonging to the 1 km south-west corner of the 5 km chunk.
format: The format of the files received, for example, csv
or gml
.
For example:
NC4040.gml
(GML geographic supply)
NC4040.csv
(CSV geographic supply)
When you receive your geo-chunked download data for GKPG, you will see a single folder on opening the data.
For example:
AddressBasePremium_FULL_2013-05-28_001_gpkg
(GPKG full supply)
If the data has been provided in a ZIP file, the following file naming convention will be used for CSV and GML:
ngxxyy.zip
For example:
NC4040.zip
(geographic supply zipped)
For GeoPackage supply, you will see a single zipped folder on downloading the data. For example:
AddressBasePremium_FULL_2013-05-28_001_gpkg.zip
(GeoPackage full supply)
AddressBase Premium is available as a change-only update (COU) supply for CSV and GML formats. COU supplies are not available for GPKG format.
A COU supply of data contains records or files that have changed between product refresh cycles. The primary benefit in supplying data in this way is that data volumes are smaller, reducing the amount of data that requires processing when compared to a full supply.
COU data enables a user to identify three types of change:
Deletes (CHANGE_TYPE ‘D’) are objects that have ceased to exist in your areas of interest (AOI) since the last product refresh.
Inserts (CHANGE_TYPE ‘I’) are objects that have been newly inserted into your AOI since the last product refresh.
Updates (CHANGE_TYPE ‘U’) are objects that have been updated in your AOI since the last product refresh.
A COU file for non-geographic chunked data can be identified by its naming convention as highlighted above. Any change record will be provided as a full record with the appropriate change type, as listed above.
A geographic chunked COU is not supplied as per the non-geographic chunked COU outlined above. Its file naming convention can be found above. If a single record has changed within a specified 5km tile, the entire 5km tile containing all features will be supplied. This means the user will need to remove all features that previously existed in the provided tile(s) and insert the entire new tile(s) in its place.
When users are deleting, inserting or updating features, it is up to the user to consider their archiving requirements. If deleted records are important to your business requirements, you must take appropriate action to archive previous records.
A way or thoroughfare providing a right of way on foot, by cycle or by motor vehicle, or access to more than one property. This record assigns a Unique Street Reference Number (USRN) to each street and holds the start and end coordinates of the street feature with information about surface type and classification.
The following page provides details about the attributes included with this feature, their data types in the different output formats, and other important metadata about them.
A non-persistent integer which is autogenerated and is required within the OGC GPKG format.
Attribute Name: Not provided (GML), Not provided (CSV), fid (GKPG)
Data Type: Integer
Multiplicity: [1]
Identifies this record as a Street Record (type 11).
Attribute Name: Not provided (GML), RECORD_IDENTIFIER (CSV), Not provided (GKPG)
Data Type: Integer (CSV)
Size: 2
Multiplicity: [1]
Type of record change – please see COU supply for more information.
Attribute Name: Provided in FeatureWithLifeCycle (GML), CHANGE_TYPE (CSV), change_type (GKPG)
Code List Name: ChangeTypeCode
Size: 1
Multiplicity: [1]
The order in which the records were processed in to create the data supply.
Attribute Name: Not provided (GML), PRO_ORDER (CSV), Not provided (GKPG)
Data Type: Integer
Size: 16
Multiplicity: [1]
Unique Street Reference Number (USRN) - the unique key for the record and primary key for the Street table.
Attribute Name: usrn (GML), USRN (CSV), usrn (GKPG)
Data Type: Integer
Size: 8
Multiplicity: [1]
Description of the street record type, for example whether it is a named or numbered street.
Attribute Name: recordType (GML), RECORD_TYPE (CSV), record_type (GKPG)
Code List Name: StreetRecordTypeCode
Size: 1
Multiplicity: [1]
The code which identifies the Street Naming and Numbering Authority or the Local Highway Authority.
Attribute Name: swaOrgRefNaming (GML), SWA_ORG_REF_NAMING (CSV), swa_org_ref_naming (GKPG)
Data Type: Integer
Size: 4
Multiplicity: [1]
A code identifying the current state of the Street, ‘Open’ for example.
Attribute Name: state (GML), STATE (CSV), state (GKPG)
Code List Name: StreetStateCode
Size: 1
Multiplicity: [0..1]
Date at which the street achieved its current state as referenced in the ‘State’ column.
Attribute Name: stateDate (GML), STATE_DATE (CSV), state_date (GKPG)
Condition: If State Date is present, State must also be present.
Data Type: Date
Multiplicity: [0..1]
A code to indicate the surface finish of the street.
Attribute Name: streetSurface (GML), STREET_SURFACE (CSV), street_surface (GKPG)
Code List Name: StreetSurfaceCode
Size: 1
Multiplicity: [0..1]
A code for the primary street classification, for example denoting it to be ‘open to all vehicles’.
Attribute Name: streetClassification (GML), STREET_CLASSIFICATION (CSV), street_classification (GKPG)
Code List Name: StreetClassificationCode
Size: 2
Multiplicity: [0..1]
Version number of the street record.
Attribute Name: version (GML), VERSION (CSV), version (GKPG)
Data Type: Integer
Size: 3
Multiplicity: [1]
Date this record or version was inserted into the database.
Attribute Name: Provided in FeatureWithLifeCycle (GML), STREET_START_DATE (CSV), street_start_date (GKPG)
Data Type: Date
Multiplicity: [1]
Date on which the street was closed in the product database. This can occur due to the street being permanently closed in the real world.
Attribute Name: Provided in FeatureWithLifeCycle (GML), STREET_END_DATE (CSV), street_end_date (GKPG)
Condition: If State is equal to 4, Street End Date must be populated.
Data Type: Date
Multiplicity: [0..1]
The date on which any attribute of the Record was last changed.
Attribute Name: Provided in FeatureWithLifeCycle (GML), LAST_UPDATE_DATE (CSV), last_update_date (GKPG)
Data Type: Date
Multiplicity: [1]
The date that the record was entered into the Local Authority database.
Attribute Name: Provided in FeatureWithLifeCycle (GML), RECORD_ENTRY_DATE (CSV), record_entry_date (GKPG)
Data Type: Date
Multiplicity: [1]
A value in metres defining the x and y location in accordance with the British National Grid for the start point of the street.
Attribute Name: streetStart (GML), STREET_START_X, STREET_START_Y (CSV), street_start_x, street_start_y (GKPG)
Data Type: GM_POINT (GML), Float (CSV), Double (GPKG)
Size: STREET_START_X (precision, scale) – (8, 2), STREET_START_Y (precision, scale) – (9, 2)
Multiplicity: [1]
A value defining the Latitude and Longitude start point of the street in accordance with the ETRS89 coordinate reference system.
Attribute Name: streetStartLatLong (GML), STREET_START_LAT, STREET_START_LONG (CSV), street_start_lat, street_start_long (GKPG)
Data Type: GM_POINT (GML), Float (CSV), Double (GPKG)
Size: LATITUDE (precision, scale) – (9, 7), LONGITUDE (precision, scale) – (8, 7)
Multiplicity: [1]
A value in metres defining the x and y location in accordance with the British National Grid for the end point of the street.
Attribute Name: streetEnd (GML), STREET_END_X, STREET_END_Y (CSV), street_start_lat, street_end_x, street_end_y (GKPG)
Data Type: GM_POINT (GML), Float (CSV), Double (GPKG)
Size: STREET_END_X (precision, scale) – (8, 2), STREET_END_Y (precision, scale) – (9, 2)
Multiplicity: [1]
A value defining the Latitude and Longitude end point of the street in accordance with the ETRS89 coordinate reference system.
Attribute Name: streetEndLatLong (GML), STREET_END_LAT, STREET_END_LONG (CSV), street_end_lat, street_end_long (GKPG)
Data Type: GM_POINT (GML), Float (CSV), Double (GPKG)
Size: LATITUDE (precision, scale) – (9, 7), LONGITUDE (precision, scale) – (8, 7)
Multiplicity: [1]
The accuracy of data capture (in metres) to which the Street Start and End coordinates have been captured.
Attribute Name: streetTolerance (GML), STREET_TOLERANCE (CSV), street_tolerance (GKPG)
Data Type: Integer
Size: 3
Multiplicity: [1]
The pages in this section describes the structured data types which make up the AddressBase Premium product.
This feature holds the lifecycle information about the data type record.
The following page provides details about the attributes included with this data type, their types in the different output formats, and other important metadata about them.
Date on which the record was first loaded into the database.
Attribute Name: startDate (GML), Not provided (CSV), Not provided (GKPG)
Data Type: Date
Multiplicity: [1]
The date on which the record ceased to exist.
Attribute Name: endDate (GML), Not provided (CSV), Not provided (GKPG)
Data Type: Date
Multiplicity: [0..1]
The date on which any attribute on this record was last changed.
Attribute Name: lastUpdateDate (GML), Not provided (CSV), Not provided (GKPG)
Data Type: Date
Multiplicity: [0..1]
The date on which the record was entered into the Local Authority database.
Attribute Name: entryDate (GML), Not provided (CSV), Not provided (GKPG)
Data Type: Date
Multiplicity: [1]
The AddressBase Premium product is distributed as comma-separated value (CSV), Geography Markup Language (GML) version 3.2.1 or GeoPackage (GPKG) formats. The CSV and GML formats can be supplied as a full supply or a change-only update (COU); the GPKG format is available as a full supply only.
The CSV supply of AddressBase Premium means:
There will be one record per line in each file.
Fields will be separated by commas.
String fields will be delimited by double quotes.
No comma will be placed at the end of each row in the file.
Records will be terminated by Carriage Return / Line Feed.
Double quotes inside strings will be escaped by doubling.
Where a field has no value in a record, two commas will be placed together in the record (one for the end of the previous field and one for the end of the null field). Where the null field is a text field double quotes will be included between the two commas, for example - , “”,
AddressBase Premium CSV data will be transferred using Unicode encoded in UTF-8. Unicode includes all the characters in ISO-8859-14 (Welsh characters). Some accented characters are encoded differently.
The transfer will normally be in a single file, but the data can be split into multiple files using volume numbers. AddressBase Premium records are provided within continuous files cut at approximately 1 million lines as referred to above.
Street and Street Descriptor records are provided together and then a new file is started independent of count for the additional record types.
This means different record types, for example, BLPU and LPIs (see AddressBase Premium structure) can be found in the same CSV file.
The record types are provided in the following order:
Street (Type 11)
Street Descriptor (Type 15) – a new file is started after the last Street Descriptor record for your supply is reached
BLPU (Type 21)
LPI (Type 24)
Delivery Point Address (Type 28)
Organisation (Type 31)
Classification (Type 32)
Application Cross Reference (Type 23)
The GML Encoding standard is an Extensible Markup Language (XML) grammar for expressing geographical features. XML schemas are used to define and validate the format and content of GML. The XML specifications that GML is based on are available from the World Wide Web Consortium (W3C) website: http://www.w3.org. More information can be found in the Open Geospatial Consortium (OGC) document, Geography Markup Language v3.2.1.
The GML 3.2.1 specification provides a set of schemas that define the GML feature constructs and geometric types. These are designed to be used as a basis for building application-specific schemas, which define the data content.
A GML document is described using an XML schema. The AddressBase Premium schema document (addressbasepremium.xml) defines the features in AddressBase Premium GML and is available on the Ordnance Survey website at: https://www.ordnancesurvey.co.uk/xml/products/AddressBasePremium.xml. It imports the GML 3.2.1 schemas which rely on XML, as defined by W3C at: http://www.w3.org/XML/1998/namespace.html.
The application schema uses the following XML namespaces:
Information about Unicode and UTF-8, the character encoding we have chosen, is available on the Unicode Consortium website.
Each feature within the AddressBaseSupplySet:FeatureCollection is encapsulated in the following member element according to its feature type:
Feature Type: BasicLandPropertyUnit
Member Element: <abpr:basicLandPropertyUnitMember>
The UPRN of the feature is provided in the XML attribute of the gml:id
Feature Type: Street
Member Element: <abpr:streetMember>
The USRN of the feature is provided in the XML attribute of the gml:id
See Example records > GML supply for specific GML examples.
In the GML supply, you can determine the extent of your supply by the <gml: Envelope>
. For example:
GPKG is an open, standards-based data format as defined by the Open Geospatial Consortium (OGC). It is designed to be a lightweight format that can contain large amounts of varied and complex data in a single, easy to distribute and ready to use file. Please be advised that older versions of GIS software may need updating before being able to display and interact with GPKG files.
GPKG offers the following benefits:
The single file is easy to transfer and offers the end-user a rich experience.
Attribute names are not limited in length, making it user friendly.
The file size limit is very large at 140 TB1, so lots of data can be easily accommodated.
It supports raster, vector and database formats, making it a highly versatile solution.
It is an OGC Standard.
In most cases, it is a plug-in-and-play format.
Application cross reference links to third-party identifiers.
AddressBase Premium application cross references contain a lookup between the AddressBase Premium UPRN and the unique identifiers of other relevant datasets.
The following page provides details about the attributes included with this data type, their types in the different output formats, and other important metadata about them.
A non-persistent integer which is autogenerated and is required within the OGC GPKG format.
Attribute Name: Not provided (GML), Not provided (CSV), fid (GKPG)
Data Type: Integer
Multiplicity: [1]
Identifies this record as an Application Cross Reference Record (type 23).
Attribute Name: Not provided (GML), RECORD_IDENTIFIER (CSV), Not provided (GKPG)
Data Type: Integer
Size: 2
Multiplicity: [1]
Attribute Name: Not provided (GML), CHANGE_TYPE (CSV), change_type (GKPG)
Size: 1
Multiplicity: [1]
The order in which the records were processed in to create the data supply.
Attribute Name: Not provided (GML), PRO_ORDER (CSV), Not provided (GKPG)
Data Type: Integer
Size: 16
Multiplicity: [1]
Unique Property Reference Number (UPRN) - foreign key used to reference the application cross reference record to the corresponding BLPU.
Attribute Name: Not provided (GML), UPRN (CSV), uprn (GKPG)
Data Type: Integer
Size: 12
Multiplicity: [1]
Unique key for the application cross reference record and primary key for this table.
Attribute Name: xrefKey (GML), XREF_KEY (CSV), xref_key (GKPG)
Data Type: CharacterString (GML), char (CSV), String (GKPG)
Size: 14
Multiplicity: [1]
Primary key of corresponding record in an external dataset.
Attribute Name: crossReference (GML), CROSS_REFERENCE (CSV), cross_reference (GKPG)
Data Type: CharacterString (GML), char (CSV), String (GKPG)
Size: 50
Multiplicity: [1]
Certain data sources may reference objects with lifecycles. This field enables users to reference specific versions of an object, for example, OS MasterMap Topographic Layer TOID and Version.
Attribute Name: version (GML), VERSION (CSV), version (GKPG)
Condition: Version must be present if Source value is one of the following: 7666MT, 7666MA or 7666MI.
Data Type: Integer
Size: 3
Multiplicity: [0..1]
External dataset identity.
Attribute Name: source (GML), SOURCE (CSV), source (GKPG)
Data Type: CharacterString (GML), char (CSV), String (GKPG)
Size: 6
Multiplicity: [1]
Date the feature was matched to the cross reference dataset for the first time.
Data Type: Date
Multiplicity: [1]
The date on which the external cross reference was no longer valid.
Data Type: Date
Multiplicity: [0..1]
The date on which any attribute on this record was last changed.
Data Type: Date
Multiplicity: [1]
The date on which the Local Authority record matched to the cross reference was inserted into the Local Authority database.
Data Type: Date
Multiplicity: [1]
The values in this table are not a code list and may be amended or extended in the future.
A descriptive identifier providing additional information about the street feature. This record holds information about locality, town name and street name.
The following page provides details about the attributes included with this data type, their types in the different output formats, and other important metadata about them.
A non-persistent integer which is autogenerated and is required within the OGC GPKG format.
Attribute Name: Not provided (GML), Not provided (CSV), fid (GKPG)
Data Type: Integer
Multiplicity: [1]
Identifies this record as a Street Descriptor record (type 15).
Attribute Name: Not provided (GML), RECORD_IDENTIFIER (CSV), Not provided (GKPG)
Data Type: Integer
Size: 2
Multiplicity: [1]
Attribute Name: Not provided (GML), CHANGE_TYPE (CSV), change_type (GKPG)
Size: 1
Multiplicity: [1]
The order in which the records were processed in to create the data supply.
Attribute Name: Not provided (GML), PRO_ORDER (CSV), Not provided (GKPG)
Data Type: Integer
Size: 16
Multiplicity: [1]
Unique Street Reference Number (USRN): used as foreign key to reference the corresponding street record.
Attribute Name: usrn (GML), USRN (CSV), usrn (GKPG)
Data Type: Integer
Size: 8
Multiplicity: [1]
Name, description or Street number for this record.
Attribute Name: streetDescription (GML), STREET_DESCRIPTION (CSV), street_description (GKPG)
Data Type: LocalisedCharacterString (GML), char (CSV), String (GKPG)
Size: 100
Multiplicity: [1]
A locality defines an area or geographical identifier within a town, village or hamlet. Locality represents the lower-level geographical area. The locality field should be used in conjunction with the town name and street description fields to uniquely identify geographic area where there may be more than one within an administrative area.
Attribute Name: locality (GML), LOCALITY (CSV), locality (GKPG)
Data Type: LocalisedCharacterString (GML), char (CSV), String (GKPG)
Size: 35
Multiplicity: [0..1]
The town name.
Attribute Name: townName (GML), TOWN_NAME (CSV), town_name (GKPG)
Condition: Town name must be present if the Street Record Type is 1 or 2 and may be entered for type 3, 4 and 9 Streets.
Data Type: LocalisedCharacterString (GML), char (CSV), String (GKPG)
Size: 30
Multiplicity: [0..1]
Local Highway Authority name for the area this record exists within.
Attribute Name: administrativeArea (GML), ADMINSTRATIVE_AREA (CSV), administrative_area (GKPG)
Data Type: LocalisedCharacterString (GML), char (CSV), String (GKPG)
Size: 30
Multiplicity: [1]
A code identifying the language in use for the record.
For GML language qualifiers are provided in the parent element as ‘xml:lang’
Attribute Name: Not provided (GML), LANGUAGE (CSV), language (GKPG)
Size: 3
Multiplicity: [1]
Date this record was first created in the database.
Data Type: Date
Multiplicity: [1]
The date on which this record ceased to exist.
Data Type: Date
Multiplicity: [0..1]
The date on which an attribute on this record was last changed.
Data Type: Date
Multiplicity: [1]
The date on which the record was entered into the Local Authority database.
Data Type: Date
Multiplicity: [1]
A BLPU is defined as a real-world object that is an ‘area of land, property or structure of fixed location having uniform occupation, ownership or function’. It is a real-world object that is of interest and within scope of the CLASS_SCHEME.
The following page provides details about the attributes included with this feature, their data types in the different output formats, and other important metadata about them.
A non-persistent integer which is autogenerated and is required within the OGC GPKG format.
Attribute Name: Not provided (GML), Not provided (CSV), fid (GKPG)
Data Type: Integer
Multiplicity: [1]
Identifies this record as a BLPU Record (type 21).
Attribute Name: Not provided (GML), RECORD_IDENTIFIER (CSV), Not provided (GKPG)
Data Type: Integer (CSV)
Size: 2
Multiplicity: [1]
Size: 1
Multiplicity: [1]
The order in which the records were processed in to create the data supply.
Attribute Name: Not provided (GML), PRO_ORDER (CSV), Not provided (GKPG)
Data Type: Integer
Size: 16
Multiplicity: [1]
The order in which the records were processed in to create the data supply.
Attribute Name: uprn (GML), UPRN (CSV), uprn (GKPG)
Data Type: Integer
Size: 12
Multiplicity: [1]
Logical status of this address record as given by the local custodian. This attribute shows whether the address is currently live, provisional or historic.
Attribute Name: logicalStatus (GML), LOGICAL_STATUS (CSV), logical_status (GKPG)
Size: 1
Multiplicity: [1]
A code identifying the current state of the BLPU.
Attribute Name: blpuState (GML), BLPU_STATE (CSV), blpu_state (GKPG)
Size: 1
Multiplicity: [0..1]
Date at which the BLPU achieved its current state as defined in the BLPU State field.
Attribute Name: blpuStateDate (GML), BLPU_STATE_DATE (CSV), blpu_state_date (GKPG)
Condition: BLPU State Date must be present if BLPU State is present.
Data Type: Date
Size: 1
Multiplicity: [0..1]
UPRN of the parent Record if a parent-child relationship exists.
Attribute Name: parentUPRN (GML), PARENT_UPRN (CSV), parent_uprn (GKPG)
Data Type: Integer
Size: 12
Multiplicity: [0..1]
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), x_coordinate, y_coordinate (GKPG)
Data Type: GM_POINT (GML), Float (CSV), Double (GPKG)
Size: X_COORDINATE (precision, scale) – (8, 2), Y_COORDINATE (precision, scale) – (9, 2)
Multiplicity: [1]
A value in metres defining the x and y location in accordance with the British National Grid.
Attribute Name: positionLatLong (GML), LATITUDE, LONGITUDE (CSV), latitude, longitude (GKPG)
Data Type: GM_POINT (GML), Float (CSV), Double (GPKG)
Size: latitude, longitude
Multiplicity: [1]
Representative Point Code: this describes the accuracy of the coordinate that has been allocated to the BLPU as indicated by the local authority custodian.
Attribute Name: rpc (GML), RPC (CSV), rpc (GKPG)
Size: 1
Multiplicity: [1]
Unique identifier of the Local Authority Custodian responsible for the maintenance of this record.
Attribute Name: localCustodianCode (GML), LOCAL_CUSTODIAN_C ODE (CSV), local_custodian_code (GKPG)
Data Type: Integer
Size: 4
Multiplicity: [1]
Attribute Name: country (GML), COUNTRY (CSV), country (GKPG)
Size: 1
Multiplicity: [1]
The date on which the address record was inserted into the database.
Data Type: Date
Multiplicity: [1]
The date on which the address record was closed in the database.
Data Type: Date
Multiplicity: [0..1]
The date on which any of the attributes on this record were last changed.
Data Type: Date
Multiplicity: [1]
The date on which this record was inserted into the Local Authority database.
Data Type: Date
Multiplicity: [1]
Identifies addresses which are believed to be capable of receiving mail as defined specifically for the AddressBase products and details their relationship with other AddressBase Postal records.
This field identifies some addresses which the AddressBase product believes to be capable of receiving mail which are not contained within the Royal Mail PAF database, such as flats behind a front door with single letter box.
Attribute Name: addressbasePostal (GML), ADDRESSBASE_POSTAL (CSV), addressbase_postal (GKPG)
Size: 1
Multiplicity: [1]
This field contains the Royal Mail Postcode Address File (PAF) postcode where the local authority address has been matched to PAF, that is, the POSTCODE field found within the Delivery Point Address table. Where a match has not been made, the postcode information is sourced from the local authority in collaboration with Royal Mail. Where the local authority does not hold a current valid postcode, a nearest neighbour function is used to spatially derive the postcode based on the position of the nearest UPRN which has a valid PAF match or valid local authority postcode assigned to it. The postcode value for Street Records (Classification "PS") will always be spatially assigned. This field must be used in conjunction with the RPC field to determine the accuracy of its position.
Attribute Name: postcodeLocator (GML), POSTCODE_LOCATOR (CSV), postcode_locator (GKPG)
Data Type: CharacterString (GML), char (CSV), String (GPKG)
Size: 8
Multiplicity: [1]
This is a count of all of the child UPRNs for this record where a parent-child relationship exists.
Attribute Name: multiOccCount (GML), MULTI_OCC_COUNT (CSV), multi_occ_count (GKPG)
Data Type: Integer
Size: 4
Multiplicity: [1]
This record holds references to a UPRN and to any replacement UPRN, for example, if a building is split into two sub-buildings; the sub-building UPRNs will be referenced in the successor record.
Please note that this record type is not currently utilised in the product.
The following page provides details about the attributes included with this data type, their types in the different output formats, and other important metadata about them.
A non-persistent integer which is autogenerated and is required within the OGC GPKG format.
Attribute Name: Not provided (GML), Not provided (CSV), fid (GKPG)
Data Type: Integer
Multiplicity: [1]
Identifies this record as a Successor Cross Reference (type 30).
Attribute Name: Not provided (GML), RECORD_IDENTIFIER (CSV), Not provided (GKPG)
Data Type: Integer
Size: 2
Multiplicity: [1]
Attribute Name: Not provided (GML), CHANGE_TYPE (CSV), change_type (GKPG)
Size: 1
Multiplicity: [1]
The order in which the records were processed in to create the data supply.
Attribute Name: Not provided (GML), PRO_ORDER (CSV), Not provided (GKPG)
Data Type: Integer
Size: 16
Multiplicity: [1]
Unique Property Reference Number (UPRN) - foreign key used to reference the LPI to the corresponding BLPU.
Attribute Name: Not provided (GML), UPRN (CSV), uprn (GKPG)
Data Type: Integer
Size: 12
Multiplicity: [1]
Key value to uniquely identify the successor cross reference record and the primary key for this table.
Attribute Name: succKey (GML), SUCC_KEY (CSV), succ_key (GKPG)
Data Type: CharacterString (GML), char (CSV ), String (GKPG)
Size: 14
Multiplicity: [1]
Date on which the record was first loaded into the database.
Data Type: Date
Multiplicity: [1]
The date on which the record ceased to exist.
Data Type: Date
Multiplicity: [0..1]
The date on which any attribute on this record was last changed.
Data Type: Date
Multiplicity: [1]
The date on which the UPRN attached to this record was entered into the Local Authority database.
Data Type: Date
Multiplicity: [1]
UPRN of successor BLPU.
Attribute Name: successor (GML), SUCCESSOR (CSV), successor (GKPG)
Data Type: Integer
Size: 12
Multiplicity: [1]
A Delivery Point Address is defined as a property that receives deliveries from Royal Mail. The structure of this address is taken from Royal Mail Postcode Address File (PAF) and other supplementary data files.
The following page provides details about the attributes included with this data type, their types in the different output formats, and other important metadata about them.
A non-persistent integer which is autogenerated and is required within the OGC GPKG format.
Attribute Name: Not provided (GML), Not provided (CSV), fid (GKPG)
Data Type: Integer
Multiplicity: [1]
Identifies the record as a Royal Mail Delivery Point Address Record (type 28).
Attribute Name: Not provided (GML), RECORD_IDENTIFIER (CSV), Not provided (GKPG)
Data Type: Integer
Size: 2
Multiplicity: [1]
Attribute Name: Not provided (GML), CHANGE_TYPE (CSV), change_type (GKPG)
Size: 1
Multiplicity: [1]
The order in which the records were processed in to create the data supply.
Attribute Name: Not provided (GML), PRO_ORDER (CSV), Not provided (GKPG)
Data Type: Integer
Size: 16
Multiplicity: [1]
Unique Property Reference Number (UPRN) - foreign key used to reference the DPA record to the corresponding BLPU.
Attribute Name: Not provided (GML), UPRN (CSV), uprn (GKPG)
Data Type: Integer
Size: 12
Multiplicity: [1]
Royal Mail’s Unique Delivery Point Reference Number (UDPRN) and the Primary key for this table.
Attribute Name: udprn (GML), UDPRN (CSV), udprn (GKPG)
Data Type: Integer
Size: 8
Multiplicity: [1]
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), organisation_name (GKPG)
Condition: Organisation Name must be present if Building Name or Building Number or PO Box Number are all not present.
Data Type: LocalisedCharacterString (GML), char (CSV), String (GKPG)
Size: 60
Multiplicity: [0..1]
Source: Royal Mail
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 RM Department Name: MARKETING DEPARTMENT
Attribute Name: departmentName (GML), DEPARTMENT_NAME (CSV), department_name (GKPG)
Condition: If a Department Name is present an Organisation Name must also be present.
Data Type: LocalisedCharacterString (GML), char (CSV), String (GKPG)
Size: 60
Multiplicity: [0..1]
Source: Royal Mail
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), sub_building_name (GKPG)
Condition: If a Sub Building Name is present a Building Name or Building Number must also be present.
Data Type: LocalisedCharacterString (GML), char (CSV), String (GKPG)
Size: 30
Multiplicity: [0..1]
Source: Royal Mail
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), building_name (GKPG)
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), String (GKPG)
Size: 50
Multiplicity: [0..1]
Source: Royal Mail
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 building name or the sub- building name fields.
Attribute Name: buildingNumber (GML), BUILDING_NUMBER (CSV), building_number (GKPG)
Condition: Building Number must be present if Organisation Name or Building Name or PO Box Number are all not present.
Data Type: Integer
Size: 4
Multiplicity: [0..1]
Source: Royal Mail
In certain places, for example, town centres, there are named thoroughfares within other named thoroughfares, for example, parades of shops on a high street where different parades have their own identity. For example, KINGS PARADE, HIGH STREET and QUEENS PARADE, HIGH STREET.
Attribute Name: dependentThoroughfare (GML), DEPENDENT_THOROUGHFARE (CSV), dependent_thoroughfare (GKPG)
Condition: If a Dependent Thoroughfare is present a Thoroughfare value must also be present.
Data Type: LocalisedCharacterString (GML), char (CSV), String (GKPG)
Size: 80
Multiplicity: [0..1]
Source: Royal Mail
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), thoroughfare (GKPG)
Data Type: LocalisedCharacterString (GML), char (CSV), String (GKPG)
Size: 80
Multiplicity: [0..1]
Source: Royal Mail
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_LOC ALITY (CSV), double_dependent_locality (GKPG)
Condition: If a Double Dependent Locality is present a Dependent Locality must also be present.
Data Type: LocalisedCharacterString (GML), char (CSV), String (GKPG)
Size: 35
Multiplicity: [0..1]
Source: Royal Mail
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_LOC ALITY (CSV), dependent_locality (GKPG)
Data Type: LocalisedCharacterString (GML), char (CSV), String (GKPG)
Size: 35
Multiplicity: [0..1]
Source: Royal Mail
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), post_town (GKPG)
Data Type: LocalisedCharacterString (GML), char (CSV), String (GKPG)
Size: 30
Multiplicity: [1]
Source: Royal Mail
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), postcode (GKPG)
Data Type: LocalisedCharacterString (GML), char (CSV), String (GKPG)
Size: 8
Multiplicity: [1]
Source: Royal Mail
Describes the address as a small or large user as defined by Royal Mail.
Attribute Name: postcodeType (GML), POSTCODE_TYPE (CSV), postcode_type (GKPG)
Condition: If PO Box number is present, Postcode Type must be ‘L’.
Size: 1
Multiplicity: [1]
Source: Royal Mail
A two-character code uniquely identifying an individual delivery point within a postcode.
Attribute Name: deliveryPointSuffix (GML), DELIVERY_POINT_SUFFIX (CSV), delivery_point_suffix (GKPG)
Condition: If PO Box number is present, Postcode Type must be ‘L’.
Code List Name: CharacterString (GML), char (CSV), String (GKPG)
Size: 2
Multiplicity: [1]
Source: Royal Mail
The Welsh translation of DEPENDENT_THOROUGHFARE.
Attribute Name: welshDependentThoroughfare (GML), WELSH_DEPENDENT_THOROUGHFARE (CSV), welsh_dependent_thoroughfare (GKPG)
Condition: If a Welsh Dependent Thoroughfare is present, a Welsh Thoroughfare must also be present.
Data Type: LocalisedCharacterString (GML), char (CSV), String (GKPG)
Size: 80
Multiplicity: [0..1]
Source: Royal Mail
The Welsh translation of THOROUGHFARE.
Attribute Name: welshThoroughfare (GML), WELSH_THOROUGHFARE (CSV), welsh_thoroughfare (GKPG)
Data Type: LocalisedCharacterString (GML), char (CSV), String (GKPG)
Size: 80
Multiplicity: [0..1]
Source: Royal Mail
The Welsh translation of Double Dependent Locality.
Attribute Name: welshDoubleDependentLocality (GML), WELSH_DOUBLE_DEPENDE NT_LOCALITY (CSV), welsh_double_dependent_locality (GKPG)
Condition: If a Welsh Double Dependent Locality is present, a Welsh Dependent Locality must also be present.
Data Type: LocalisedCharacterString (GML), char (CSV), String (GKPG)
Size: 36
Multiplicity: [0..1]
Source: Royal Mail
The Welsh translation of DEPENDENT_LOCALITY.
Attribute Name: welshDependentLocality (GML), WELSH_DEPENDENT_LOCALITY (CSV), welsh_dependent_locality (GKPG)
Condition: If a Welsh Double Dependent Locality is present, a Welsh Dependent Locality must also be present.
Data Type: LocalisedCharacterString (GML), char (CSV), String (GKPG)
Size: 35
Multiplicity: [0..1]
Source: Royal Mail
The Welsh translation of post town value.
Attribute Name: welshPostTown (GML), WELSH_POST_TOWN (CSV), welsh_post_town (GKPG)
Data Type: LocalisedCharacterString (GML), char (CSV), String (GKPG)
Size: 30
Multiplicity: [0..1]
Source: Royal Mail
Post Office Box (PO Box) number.
Attribute Name: poBoxNumber (GML), PO_BOX_NUMBER (CSV), po_box_number (GKPG)
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), String (GKPG)
Size: 6
Multiplicity: [0..1]
Source: Royal Mail
The date on which the PAF record was processed into the database.
Attribute Name: processDate (GML), PROCESS_DATE (CSV), process_date (GKPG)
Data Type: Date
Multiplicity: [1]
The date on which the address record was matched to the Delivery Point Address.
Data Type: Date
Multiplicity: [1]
The date on which the PAF record no longer existed in the database.
Data Type: Date
Multiplicity: [0..1]
The date on which any attribute on this record was last changed.
Data Type: Date
Multiplicity: [1]
The date on which the PAF record was first loaded by Geoplace.
Data Type: Date
Multiplicity: [1]
A structured entry identifying the name of the current non-domestic occupier of the BLPU. This record holds information about the organisation of the record.
The following page provides details about the attributes included with this data type, their types in the different output formats, and other important metadata about them.
A non-persistent integer which is autogenerated and is required within the OGC GPKG format.
Attribute Name: Not provided (GML), Not provided (CSV), fid (GKPG)
Data Type: Integer
Multiplicity: [1]
Identifies this as an Organisation Record (type 31).
Attribute Name: Not provided (GML), RECORD_IDENTIFIER (CSV), Not provided (GKPG)
Data Type: Integer
Size: 2
Multiplicity: [1]
Attribute Name: Not provided (GML), CHANGE_TYPE (CSV), change_type (GKPG)
Size: 1
Multiplicity: [1]
The order in which the records were processed in to create the data supply.
Attribute Name: Not provided (GML), PRO_ORDER (CSV), Not provided (GKPG)
Data Type: Integer
Size: 16
Multiplicity: [1]
Unique Property Reference Number (UPRN) - foreign key used to reference the LPI to the corresponding BLPU.
Attribute Name: Not provided (GML), UPRN (CSV), uprn (GKPG)
Data Type: Integer
Size: 12
Multiplicity: [1]
Unique key for the organisation record and primary key for this table.
Attribute Name: orgKey (GML), ORG_KEY (CSV), org_key (GKPG)
Data Type: CharacterString (GML), char (CSV),
String (GKPG)
Size: 14
Multiplicity: [1]
Name of the organisation currently occupying the address record as provided by the local authority custodian.
Attribute Name: organisation (GML), ORGANISATION (CSV), organisation (GKPG)
Data Type: CharacterString (GML), char (CSV), String (GKPG)
Size: 100
Multiplicity: [1]
Registered legal name of the organisation.
Attribute Name: legalName (GML), LEGAL_NAME (CSV), legal_name (GKPG)
Data Type: CharacterString (GML), char (CSV), String (GKPG)
Size: 60
Multiplicity: [0..1]
Date on which the record was first loaded into the database.
Data Type: Date
Multiplicity: [1]
The date on which the record ceased to exist.
Data Type: Date
Multiplicity: [0..1]
The date on which any attribute on this record was last changed.
Data Type: Date
Multiplicity: [1]
The date on which the UPRN attached to this record was entered into the Local Authority database.
Data Type: Date
Multiplicity: [1]
A structured entry that provides the code for the type of BLPU and the classification scheme from which the code is taken. This record holds the classification of a property and allows one to search upon the use of a feature.
The following page provides details about the attributes included with this data type, their types in the different output formats, and other important metadata about them.
A non-persistent integer which is autogenerated and is required within the OGC GPKG format.
Attribute Name: Not provided (GML), Not provided (CSV), fid (GKPG)
Data Type: Integer
Multiplicity: [1]
Identifies this record as a Classification Record (type 32).
Attribute Name: Not provided (GML), RECORD_IDENTIFIER (CSV), Not provided (GKPG)
Data Type: Integer
Size: 2
Multiplicity: [1]
Attribute Name: Not provided (GML), CHANGE_TYPE (CSV), change_type (GKPG)
Size: 1
Multiplicity: [1]
The order in which the records were processed in to create the data supply.
Attribute Name: Not provided (GML), PRO_ORDER (CSV), Not provided (GKPG)
Data Type: Integer
Size: 16
Multiplicity: [1]
Unique Property Reference Number (UPRN) - foreign key used to reference the LPI to the corresponding BLPU.
Attribute Name: Not provided (GML), UPRN (CSV), uprn (GKPG)
Data Type: Integer
Size: 12
Multiplicity: [1]
Unique key for the classification record and primary key for this table.
Attribute Name: classKey (GML), CLASS_KEY (CSV), class_key (GKPG)
Data Type: CharacterString (GML), char (CSV), String (GKPG)
Size: 14
Multiplicity: [1]
A code that describes the classification of the record.
Attribute Name: classificationCode (GML), CLASSIFICATION_CODE (CSV), classification_code (GKPG)
Data Type: CharacterString (GML), char (CSV), String (GKPG)
Size: 6
Multiplicity: [1]
The name of the classification scheme used for this record.
Attribute Name: classScheme (GML), CLASS_SCHEME (CSV), class_scheme (GKPG)
Data Type: CharacterString (GML), char (CSV), String (GKPG)
Size: 60
Multiplicity: [1]
The name of the classification scheme used for this record.
Attribute Name: schemeVersion (GML), SCHEME_VERSION (CSV), scheme_version (GKPG)
Data Type: CharacterString (GML), float (CSV), double (GKPG)
Size: (precision, scale) – 2(1)
Multiplicity: [1]
Date on which this classification record was first loaded into the database.
Data Type: Date
Multiplicity: [1]
Date this classification record ceased to exist.
Data Type: Date
Multiplicity: [0..1]
The date on which any attribute on this record was last changed.
Data Type: Date
Multiplicity: [1]
The date on which the address record associated with this classification record was inserted into the Local Authority database.
Data Type: Date
Multiplicity: [1]
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 section will step through two such approaches that may be used when working with AddressBase Premium products: free text search and structured component search.
These methods are not intended as recommendations; they are simply examples of how to get maximum value out of the products when implementing an address search function.
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 |
---|---|
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 they may have been 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.
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).
This method guides the user to enter known components of an address and also 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 following sub-sections suggest how to implement the two search methods described above. Both methods should be used alongside the instructions on formatting single address labels given in Section 11.
As described in Creating a single-line or multi-line address above, at a high level, the AddressBase Premium products provide two different types of address: the Delivery Point Address and the Geographic Address. However, for some Geographic Addresses, an alternative, provisional or historical variant of the approved record may also be provided as well as the approved address (all sharing the same UPRN).
The table below outlines what these addresses are and how to access them in the products. It provides a breakdown of the location and definition of Delivery Point addresses and the four categories of Geographic Addresses available in AddressBase Premium products.
An address search operation typically requires two stages of interaction from a user, and several processing steps from the underlying IT system. These steps are 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.
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 the AddressBase Premium products. 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 (Delivery Point Address and Geographic Address) 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 Premium and AddressBase Premium Islands are as follows:
The table below shows the relationships between some common search fields and the fields found in AddressBase Premium and AddressBase Premium Islands.
The above mapping is an example only and it is possible to break down 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 in the table above), 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.
The basic rules to follow 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) where a street, locality and town name have been entered by the user:
In the above example, ‘streetsearchtext’, ‘localitysearchtext’, and ‘townsearchtext’ (shown in blue) represent user-entered search terms (which could be parameters within an SQL function) and the GetFormattedAddress(*) function is a hypothetical user-defined function that returns the formatted address as a single string (suitable for display in the user interface). For more information on formatting addresses, please see Creating a single-line or multi-line address.
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:
The geographic query requires four joins between the BLPU, LPI, Street Descriptor and Organisation tables in order to access all the fields required to build an address.
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: formatted addresses along with their UPRN. Exact duplicates will be omitted, but all ‘variations’ of the same address will be outputted (one row for each variation, with the same UPRN repeated more than once potentially). It may be wise to also return the ‘logical status’ and/or ‘postal address flag’ values against each to enable further filtering (that is, to include or exclude historical addresses for example, or to restrict the results to postal addresses only).
A flaw in the above examples is the use of equality operators. In practice, because people do not tend to be consistent with the capitalisation of letters, the SQL ‘LIKE’ operator might work better. 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:
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):
Finally, to combine all of the approaches, the following would work for maximum flexibility:
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.
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 ‘logical status’ values, which would allow the results to be filtered on ‘approved’, ‘provisional’ and ‘historical’ statuses, for example).
The table below shows a possible address index table structure:
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, current and historical, approved and alternative) 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.
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 the user input 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:
This query would return all rows from the index table that contain all of the search terms, along with the appropriate UPRNs.
The table below shows how the index table would be used in the above example to return relevant results:
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 section.
This section introduces implementing address search functionality using AddressBase Premium products. The main points are summarised below:
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, for example, ‘approved’, ‘alternative’ and ‘historical’, as well as ‘postal’ or ‘non- postal’, etc.
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).
AddressBase Premium is structured as a series of relational tables. The data structure is described by means of unified modeling language (UML) class diagrams and accompanying tables containing text.
The AddressBase Premium product is constructed as per the following UML diagrams on this page.
This diagram shows the relationships between each of the record types and their foreign keys.
A UML model of AddressBase Premium in CSV and GKPG formats can be seen in the diagram below. In the UML diagram, feature types from the Ordnance Survey product specification are orange and data types are purple.
record_identifier
and pro_order
are not included in GKPG format.
The diagram below shows a high-level data model representing the GML AddressBase Premium data model. This diagram shows the relationships between each of the record types and their foreign keys.
The diagram below is a UML model of AddressBase Premium in GML format; feature types from the Ordnance Survey product specification are orange and data types are purple.
Definition: A way or thoroughfare providing a right of way on foot, by cycle or by motor vehicle, or access to more than one property.
Description: This record assigns a Unique Street Reference Number (USRN) to each street and holds the start and end coordinates of the street feature with information about surface type and classification.
Definition: A descriptive identifier providing additional information about the street feature.
Description: This record holds information about locality, town name and street name.
Definition: A BLPU is defined as a real-world object that is an ‘area of land, property or structure of fixed location having uniform occupation, ownership or function’.
Description: A real-world object that is of interest and within scope of the CLASS_SCHEME.
Definition: Application cross reference links to third-party identifiers.
Description: AddressBase Premium application cross references contain a lookup between the AddressBase Premium UPRN and the unique identifiers of other relevant datasets.
Definition: An LPI is a structured entry that identifies a BLPU.
Description: A simple identifier or description for the object. The richness of the data structure within AddressBase Premium provides the facility to describe a BLPU by more than one LPI.
Definition: A Delivery Point Address is defined as a property that receives deliveries from Royal Mail.
Description: The structure of this address is taken from Royal Mail Postcode Address File (PAF) and other supplementary data files.
Definition: This record holds references to a UPRN and to any replacement UPRN, for example, if a building is split into two sub-buildings; the sub-building UPRNs will be referenced in the successor record.
Description: This record holds information about a UPRN and the UPRNs of the records that succeed that record.
Definition: A structured entry identifying the name of the current non-domestic occupier of the BLPU.
Description: This record holds information about the organisation of the record.
Definition: A structured entry that provides the code for the type of BLPU and the classification scheme from which the code is taken.
Description: This record holds the classification of a property and allows one to search upon the use of a feature.
The following are contained within CSV only:
Definition: A structured entry that provides key information about the source, time and supply mechanism of the AddressBase Premium file.
Definition: A structured entry providing metadata information such as the gazetteer owner, scope and character sets.
Definition: A structured entry which terminates the file. This includes information on the record counts, and next volume number.
The following are contained within GML only:
Definition: This feature holds the lifecycle information about the data type record.
Definition: This feature holds the lifecycle information about the whole feature.
AddressBaseSupplySet
Definition: This feature is formally known as the GML feature collection and is used to define a collection of features.
This feature is formally known as the GML feature collection and is used to define a collection of features.
This is not supplied as part of the CSV or GPKG supply. Please see the model overviews in for more information.
The following page provides details about the attributes included with this feature, their data types in the different output formats, and other important metadata about them.
Time the data was extracted from the database.
Attribute Name: queryTime (GML), Not provided (CSV), Not provided (GKPG)
Data Type: DateTime
Multiplicity: [1]
The date given as part of a change-only query.
Attribute Name: queryChangeSinceDate (GML), Not provided (CSV), Not provided (GKPG)
Data Type: Date
Multiplicity: [0..1]
An LPI is a structured entry that identifies a BLPU. It is a simple identifier or description for the object. The richness of the data structure within AddressBase Premium provides the facility to describe a by more than one LPI.
The following page provides details about the attributes included with this data type, their types in the different output formats, and other important metadata about them.
A non-persistent integer which is autogenerated and is required within the OGC GPKG format.
Attribute Name: Not provided (GML), Not provided (CSV), fid (GKPG)
Data Type: Integer
Multiplicity: [1]
Identifies this Record as an LPI Record (type 24).
Attribute Name: Not provided (GML), RECORD_IDENTIFIER (CSV), Not provided (GKPG)
Data Type: Integer
Size: 2
Multiplicity: [1]
Attribute Name: Not provided (GML), CHANGE_TYPE (CSV), change_type (GKPG)
Size: 1
Multiplicity: [1]
The order in which the records were processed in to create the data supply.
Attribute Name: Not provided (GML), PRO_ORDER (CSV), Not provided (GKPG)
Data Type: Integer
Size: 16
Multiplicity: [1]
Unique Property Reference Number (UPRN) - foreign key used to reference the LPI to the corresponding BLPU.
Attribute Name: Not provided (GML), UPRN (CSV), uprn (GKPG)
Data Type: Integer
Size: 12
Multiplicity: [1]
Unique key for the LPI and primary key for this table.
Attribute Name: lpiKey (GML), LPI_KEY (CSV), lpi_key (GKPG)
Data Type: CharacterString (GML), char (CSV), String (GKPG)
Size: 14
Multiplicity: [1]
For GML language qualifiers are provided in the parent element as ‘xml:lang’
A code that identifies the language used for the LPI record.
Attribute Name: Not provided (GML), LANGUAGE (CSV), language (GKPG)
Size: 3
Multiplicity: [1]
Logical status of this record.
Attribute Name: logicalStatus (GML), LOGICAL_STATUS (CSV), logical_status (GKPG)
Size: 1
Multiplicity: [1]
Date that this LPI record was first loaded into the database.
Data Type: Date
Multiplicity: [1]
The date this record ceased to exist in the database.
Data Type: Date
Multiplicity: [0..1]
The last date an attribute on this record was last changed.
Data Type: Date
Multiplicity: [1]
The date on which the record was inserted into the Local Authority database.
Data Type: Date
Multiplicity: [1]
The number of the secondary addressable object (SAO) or the start of the number range.
Attribute Name: saoStartNumber (GML), SAO_START_NUMBER (CSV), sao_start_number (GKPG)
Condition: If a SAO Start Number is present a PAO Start Number or PAO text must also be present.
Data Type: Integer
Size: 4
Multiplicity: [0..1]
The suffix to the SAO_START_NUMBER.
Attribute Name: saoStartSuffix (GML), SAO_START_SUFFIX (CSV), sao_start_suffix (GKPG)
Condition: If a SAO Start Suffix is present a SAO Start Number must also be present.
Data Type: CharacterString (GML), char (CSV), String (GKPG)
Size: 2
Multiplicity: [0..1]
The end of the number range for the SAO, where the SAO_START_NUMBER contains the first number in the range.
Attribute Name: saoEndNumber (GML), SAO_END_NUMBER (CSV), sao_end_number (GKPG)
Condition: If SAO End Number is present, a SAO Start Number must also be present.
Data Type: Integer
Size: 4
Multiplicity: [0..1]
The suffix to the SAO_END_NUMBER.
Attribute Name: saoEndSuffix (GML), SAO_END_SUFFIX (CSV), sao_end_suffix (GKPG)
Condition: If a SAO End Suffix is present, a SAO End Number must also be present.
Data Type: CharacterString (GML), char (CSV), String (GKPG)
Size: 2
Multiplicity: [0..1]
Contains the building name or description for the SAO.
Attribute Name: saoText (GML), SAO_TEXT (CSV), sao_text (GKPG)
Condition: If SAO Text is present, a PAO Start Number or PAO Text must also be present.
Data Type: LocalisedCharacterString (GML), char (CSV), String (GKPG)
Size: 90
Multiplicity: [0..1]
The number of the primary addressable object (PAO) or the start of the number range.
Attribute Name: paoStartNumber (GML), PAO_START_NUMBER (CSV), pao_start_number (GKPG)
Condition: PAO Start Number must be present if PAO Text is not present.
Data Type: Integer
Size: 4
Multiplicity: [0..1]
The suffix to the PAO_START_NUMBER.
Attribute Name: paoStartSuffix (GML), PAO_START_SUFFIX (CSV), pao_start_suffix (GKPG)
Condition: If a PAO Start Suffix is present, a PAO Start Number must also be present.
Data Type: CharacterString (GML), char (CSV), String (GKPG)
Size: 2
Multiplicity: [0..1]
The end of the number range for the PAO where the PAO_START_NUMBER contains the first number in the range.
Attribute Name: paoEndNumber (GML), PAO_END_NUMBER (CSV), pao_end_number (GKPG)
Condition: If a PAO End Number is present, a PAO Start Number must also be present.
Data Type: Integer
Size: 4
Multiplicity: [0..1]
The suffix to the PAO_END_NUMBER.
Attribute Name: paoEndSuffix (GML), PAO_END_SUFFIX (CSV), pao_end_suffix (GKPG)
Condition: If a PAO End Suffix is present, a PAO End Number must also be present.
Data Type: CharacterString (GML), char (CSV), String (GKPG)
Size: 2
Multiplicity: [0..1]
Contains the building name or description for the PAO.
Attribute Name: paoText (GML), PAO_TEXT (CSV), pao_text (GKPG)
Condition: PAO Text must be present if PAO Start Number is not present.
Data Type: LocalisedCharacterString (GML), char (CSV), String (GKPG)
Size: 90
Multiplicity: [0..1]
Unique Street Reference Number (USRN) - foreign key linking the Street record to the LPI record.
Attribute Name: usrn (GML), USRN (CSV), usrn (GKPG)
Data Type: Integer
Size: 8
Multiplicity: [1]
This field indicates how the item was matched to a Street. 1 is matched manually to the most accessible USRN and 2 is matched spatially to the nearest USRN, which may not be the nearest accessible street.
Attribute Name: usrnMatchIndicator (GML), USRN_MATCH_INDICATOR (CSV), usrn_match_indicator (GKPG)
Size: 1
Multiplicity: [1]
Third level of geographic area name, for example, to record island names or property groups such as crofts.
Attribute Name: areaName (GML), AREA_NAME (CSV), area_name (GKPG)
Data Type: CharacterString (GML), char (CSV), String (GKPG)
Size: 40
Multiplicity: [0..1]
Detail on the vertical position of the property if known and provided by the Local Authority Custodian.
Attribute Name: level (GML), LEVEL (CSV), level (GKPG)
Data Type: CharacterString (GML), char (CSV), String (GKPG)
Size: 30
Multiplicity: [0..1]
Detail on the vertical position of the property if known and provided by the Local Authority Custodian.
Attribute Name: level (GML), LEVEL (CSV), level (GKPG)
Data Type: CharacterString (GML), char (CSV), String (GKPG)
Size: 30
Multiplicity: [0..1]
Status of the Address.
Attribute Name: officialFlag (GML), OFFICIAL_FLAG (CSV), official_flag (GKPG)
Size: 1
Multiplicity: [0..1]
This feature holds the lifecycle information about the whole feature.
The following page provides details about the attributes included with this feature, their data types in the different output formats, and other important metadata about them.
Type of record change – please see for more information.
Attribute Name: changeType (GML), Not provided (CSV), Not provided (GKPG)
Code List Name:
Multiplicity: [1]
Date on which the record was first loaded into the database.
Attribute Name: startDate (GML), Not provided (CSV), Not provided (GKPG)
Data Type: Date
Multiplicity: [1]
The date on which the record ceased to exist.
Attribute Name: endDate (GML), Not provided (CSV), Not provided (GKPG)
Data Type: Date
Multiplicity: [0..1]
The date on which any attribute on this record was last changed in the product database.
Attribute Name: endDate (GML), Not provided (CSV), Not provided (GKPG)
Data Type: Date
Multiplicity: [0..1]
The date on which the record was entered into the Local Authority database.
Attribute Name: entryDate (GML), Not provided (CSV), Not provided (GKPG)
Data Type: Date
Multiplicity: [1]
Prefix | Namespace Identifier | Definition Available at |
---|---|---|
Type of record change – please see for more information.
Code List Name:
Attribute Name: Provided in (GML), START_DATE (CSV), start_date (GKPG)
Attribute Name: Provided in (GML), END_DATE (CSV), end_date (GKPG)
Attribute Name: Provided in (GML), LAST_UPDATE_DATE (CSV), last_update_date (GKPG)
Attribute Name: Provided in (GML), ENTRY_DATE (CSV), entry_date (GKPG)
Dataset ID | Data source | Multiplicity |
---|
Type of record change – please see for more information.
Code List Name:
Code List Name:
Attribute Name: Provided in (GML), START_DATE (CSV), start_date (GKPG)
Attribute Name: Provided in (GML), END_DATE (CSV), end_date (GKPG)
Attribute Name: Provided in (GML), LAST_UPDATE_DATE (CSV), last_update_date (GKPG)
Attribute Name: Provided in (GML), ENTRY_DATE (CSV), entry_date (GKPG)
Type of record change – please see for more information.
Attribute Name: Provided in (GML), CHANGE_TYPE (CSV), change_type (GKPG)
Code List Name:
Code List Name:
Code List Name:
Code List Name:
The country in which a record can be found. This is calculated by performing an intersection with OS Boundary Line. This means records such as wind and fish farms will be assigned a value of ‘J’. Please see for more information.
Code List Name:
Attribute Name: Provided in (GML), START_DATE (CSV), start_date (GKPG)
Attribute Name: Provided in (GML), END_DATE (CSV), end_date (GKPG)
Attribute Name: Provided in (GML), LAST_UPDATE_DATE (CSV), last_update_date (GKPG)
Attribute Name: Provided in (GML), ENTRY_DATE (CSV), entry_date (GKPG)
Code List Name:
Type of record change – please see for more information.
Code List Name:
Attribute Name: Provided in (GML), START_DATE (CSV), start_date (GKPG)
Attribute Name: Provided in (GML), END_DATE (CSV), end_date (GKPG)
Attribute Name: Provided in (GML), LAST_UPDATE_DATE (CSV), last_update_date (GKPG)
Attribute Name: Provided in (GML), ENTRY_DATE (CSV), entry_date (GKPG)
Type of record change – please see for more information.
Code List Name:
Code List Name:
Attribute Name: Provided in (GML), START_DATE (CSV), start_date (GKPG)
Attribute Name: Provided in (GML), END_DATE (CSV), end_date (GKPG)
Attribute Name: Provided in (GML), LAST_UPDATE_DATE (CSV), last_update_date (GKPG)
Attribute Name: Provided in (GML), ENTRY_DATE (CSV), entry_date (GKPG)
Type of record change – please see for more information.
Code List Name:
Attribute Name: Provided in (GML), START_DATE (CSV), start_date (GKPG)
Attribute Name: Provided in (GML), END_DATE (CSV), end_date (GKPG)
Attribute Name: Provided in (GML), LAST_UPDATE_DATE (CSV), last_update_date (GKPG)
Attribute Name: Provided in (GML), ENTRY_DATE (CSV), entry_date (GKPG)
Type of record change – please see for more information.
Code List Name:
Attribute Name: Provided in (GML), START_DATE (CSV), start_date (GKPG)
Attribute Name: Provided in (GML), END_DATE (CSV), end_date (GKPG)
Attribute Name: Provided in (GML), LAST_UPDATE_DATE (CSV), last_update_date (GKPG)
Attribute Name: Provided in (GML), ENTRY_DATE (CSV), entry_date (GKPG)
Results |
---|
Address type | What is it? | Where is it? |
---|---|---|
Search Box | Mapped Delivery Point fields | Mapped Geographic fields |
---|---|---|
SQL code | Description |
---|---|
SQL code | Description |
---|---|
SQL code |
---|
UPRN | Address Text | Statuses (multiple fields) |
---|---|---|
UPRN | Address Text | Statuses (multiple fields) |
---|---|---|
Type of record change – please see for more information.
Code List Name:
Code List Name:
Code List Name:
Attribute Name: Provided in (GML), START_DATE (CSV), start_date (GKPG)
Attribute Name: Provided in (GML), END_DATE (CSV), end_date (GKPG)
Attribute Name: Provided in (GML), LAST_UPDATE_DATE (CSV), last_update_date (GKPG)
Attribute Name: Provided in (GML), ENTRY_DATE (CSV), entry_date (GKPG)
Code List Name:
Code List Name:
gml
xsi
Built into XML – http://www.w3.org/TR/xmlschema-1/
xlink
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...
Delivery Point Address
The postal address as assigned to the property by Royal Mail (and widely used by the public).
Delivery Point Address table.
Approved Geographic Address
The legal / approved address as assigned by the local naming and numbering authority.
LPI table with Logical Status = 1, joined to Street Descriptor, Organisation and BLPU tables.
Provisional Geographic Address
Provisional addresses may exist for a property from the moment that an address has been granted planning permission to be built to the time when construction has been completed.
LPI table with Logical Status = 6, joined to Street Descriptor, Organisation and BLPU tables.
Alternative Geographic Address
Any alternative addresses that may exist for this property (for example, alternative names). There may be more than one alternative address per property.
LPI table with Logical Status = 3, joined to Street Descriptor, Organisation and BLPU tables.
Historical Geographic Address
Any historical addresses (recorded since data collection began) that may have existed in the past for this property (for example, previous house names or business names, and so on). There may be more than one historical address per property.
LPI table with Logical Status = 8, joined to Street Descriptor, Organisation and BLPU tables.
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
dp.post_town LIKE townsearchtext
Case insensitive search in some databases
dp.post_town LIKE (townsearchtext || ‘%’)
Matches post towns that start with the search text
dp.post_town LIKE (‘%’ || townsearchtext || ‘%’)
Matches post towns that contain the search text
UPPER(dp.post_town) = UPPER(townsearchtext)
Case insensitive equality
UPPER(dp.post_town) LIKE (‘%’ || UPPER(townsearchtext) || ‘%’)
123456789012
4 THE MEADOWS HIGH STREET WALTHAMSDALE BURRIDGE BU27 9UB
Approved
123456789012
FLAT 4 THE MEADOWS HIGH STREET WALTHAMSDALE BURRIDGE BU27 9UB
Alternative + PAF
123456789012
4 HIGH STREET WALTHAMSDALE CLOSE BURRIDGE BU27 9UB
Historical
947364758903
ROSE COTTAGE MAIN STREET HAVERSHAM SUDBURY SU45 9TY
Approved + PAF
947364758903
ROSE FARMHOUSE MAIN STREET HAVERSHAM SUDBURY
Historical
894756389092
4 HIGH STREET WESTVILLE SUNNYTOWN WV17 7HL
Approved + PAF
894756389092
ROSE COTTAGE 4 HIGH STREET WESTVILLE SUNNYTOWN WV17 7HL
Alternative
894756389092
ROSE COTTAGE HIGH STREET WESTVILLE SUNNYTOWN WV17 7HL
Alternative
274859037849
FLAT 4 HIGHBURY COURT HIGH STREET WESTVILLE SUNNYTOWN WV17 7HL
Approved + PAF
482974769830
MAPS4U LTD HIGH STREET WESTVILLE SUNNYTOWN WV17 7HL
Approved
7666MT | OS MasterMap Topography Layer TOID. | [0..1] |
7666MA | OS MasterMap Address Layer 2 TOID. | [0..1] |
7666MI | OS MasterMap Highways TOID. | [0..1] |
7666VC | Centrally created Council Tax. | [0..1] |
7666VN | Centrally created non domestic rates. | [0..1] |
7666OW | ONS Ward Code. | [0..1] |
7666OP | ONS Parish Code. | [0..1] |
A structured entry providing metadata information such as the gazetteer owner, scope and character sets.
A Metadata record is not provided in GML or GPKG
The following page provides details about the attributes included with this data type, their types in the different output formats, and other important metadata about them.
Identifies the record as a Metadata Record (type 29).
Attribute Name: Not provided (GML), RECORD_IDENTIFIER (CSV), Not provided (GKPG)
Data Type: Integer
Size: 2
Multiplicity: [1]
Name of the Gazetteer, this will most likely reflect the product name, for example, AddressBase Premium.
Attribute Name: Not provided (GML), GAZ_NAME (CSV), Not provided (GKPG)
Data Type: char
Size: 60
Multiplicity: [1]
Description of the content of the gazetteer.
Attribute Name: Not provided (GML), GAZ_SCOPE (CSV), Not provided (GKPG)
Data Type: char
Size: 60
Multiplicity: [1]
Geographic domain of the gazetteer, for example, England, Wales and Scotland.
Attribute Name: Not provided (GML), TER_OF_USE (CSV), Not provided (GKPG)
Data Type: char
Size: 60
Multiplicity: [1]
List of other datasets used to contribute to the creation of the product.
Attribute Name: Not provided (GML), LINKED_DATA (CSV), Not provided (GKPG)
Data Type: char
Size: 100
Multiplicity: [1]
The organisation with overall responsibility for the gazetteer.
Attribute Name: Not provided (GML), GAZ_OWNER (CSV), Not provided (GKPG)
Data Type: char
Size: 15
Multiplicity: [1]
The frequency with which the data is maintained and sent to the customer.
Attribute Name: Not provided (GML), NGAZ_FREQ (CSV), Not provided (GKPG)
Data Type: char
Size: 1
Multiplicity: [1]
Organisation or department responsible for the compilation and maintenance of the data, for example Geoplace.
Attribute Name: Not provided (GML), CUSTODIAN_NAME (CSV), Not provided (GKPG)
Data Type: char
Size: 40
Multiplicity: [1]
Four-digit code identifying the gazetteer custodian.
Attribute Name: Not provided (GML), LOCAL_CUSTODIAN_CODE (CSV), Not provided (GKPG)
Data Type: Integer
Size: 4
Multiplicity: [1]
Coordinate Reference System used in the gazetteer to describe the position, for example British National Grid.
Attribute Name: Not provided (GML), CO_ORD_SYSTEM (CSV), Not provided (GKPG)
Data Type: char
Size: 40
Multiplicity: [1]
Unit of measurement of coordinates.
Attribute Name: Not provided (GML), CO_ORD_SYSTEM (CSV), Not provided (GKPG)
Data Type: char
Size: 10
Multiplicity: [1]
Date metadata was last updated.
Attribute Name: Not provided (GML), META_DATE (CSV), Not provided (GKPG)
Data Type: Date
Multiplicity: [1]
Classification scheme (s) used in the Gazetteer.
Attribute Name: Not provided (GML), CLASS_SCHEME (CSV), Not provided (GKPG)
Data Type: char
Size: 60
Multiplicity: [1]
Date at which the gazetteer can be considered to be current.
Attribute Name: Not provided (GML), GAZ_DATE (CSV), Not provided (GKPG)
Data Type: Date
Multiplicity: [1]
Language used for the descriptors within the gazetteer, for example ‘ENG’.
Attribute Name: Not provided (GML), CLASS_SCHEME (CSV), Not provided (GKPG)
Code List Name: LanguageCode
Size: 3
Multiplicity: [1]
The character set used in this gazetteer.
Attribute Name: Not provided (GML), CHARACTER_SET (CSV), Not provided (GKPG)
Data Type: char
Size: 30
Multiplicity: [1]
A structured entry which terminates the file. This includes information on the record counts, and next volume number.
A Trailer record is not provided in GML or GPKG
The following page provides details about the attributes included with this data type, their types in the different output formats, and other important metadata about them.
Identifies the record as a Trailer Record (type 99).
Attribute Name: Not provided (GML), RECORD_IDENTIFIER (CSV), Not provided (GKPG)
Data Type: Integer
Size: 2
Multiplicity: [1]
The sequential number of the next volume in the transfer set. For geographic supply this will always be zero (0). For non-geographic supply zero (0) will denote the last file in the transfer set.
Attribute Name: Not provided (GML), NEXT_VOLUME_NAME (CSV), Not provided (GKPG)
Data Type: Integer
Size: 3
Multiplicity: [1]
The sequential number of the next volume in the transfer set. For geographic supply this will always be zero (0). For non-geographic supply zero (0) will denote the last file in the transfer set.
Attribute Name: Not provided (GML), NEXT_VOLUME_NAME (CSV), Not provided (GKPG)
Data Type: Integer
Size: 3
Multiplicity: [1]
Count of the number of records in the volume (excluding the header record, metadata and trailer records).
Attribute Name: Not provided (GML), RECORD_COUNT (CSV), Not provided (GKPG)
Data Type: Integer
Size: 16
Multiplicity: [1]
The date of data entry.
Attribute Name: Not provided (GML), ENTRY_DATE (CSV), Not provided (GKPG)
Data Type: Date
Multiplicity: [1]
Time of creation in HH:MM:SS format.
Attribute Name: Not provided (GML), TIME_STAMP (CSV), Not provided (GKPG)
Data Type: Time
Multiplicity: [1]
A structured entry that provides key information about the source, time and supply mechanism of the AddressBase Premium file.
A Header record is not provided in GML or GPKG
The following page provides details about the attributes included with this data type, their types in the different output formats, and other important metadata about them.
Identifies the record as a Header Record (type 10).
Attribute Name: Not provided (GML), RECORD_IDENTIFIER (CSV), Not provided (GKPG)
Data Type: Integer
Size: 2
Multiplicity: [1]
Name of the data provider organisation.
Attribute Name: Not provided (GML), CUSTODIAN_NAME (CSV), Not provided (GKPG)
Data Type: char
Size: 40
Multiplicity: [1]
Unique identifier for the data provider code.
Attribute Name: Not provided (GML), LOCAL_CUSTODIAN_CODE (CSV), Not provided (GKPG)
Data Type: Integer
Size: 4
Multiplicity: [1]
The date on which the data supply was generated.
Attribute Name: Not provided (GML), PROCESS_DATE (CSV), Not provided (GKPG)
Data Type: Date
Multiplicity: [1]
The sequential number of the volume in the transfer set.
For Geographic supplies, this number will always be zero ‘0’.
Attribute Name: Not provided (GML), VOLUME_NUMBER (CSV), Not provided (GKPG)
Data Type: Integer
Size: 3
Multiplicity: [1]
Date of data entry for this volume.
Attribute Name: Not provided (GML), ENTRY_DATE (CSV), Not provided (GKPG)
Data Type: Date
Multiplicity: [1]
Time of file creation in HH:MM:SS format in a 24-hour clock.
Attribute Name: Not provided (GML), TIME_STAMP (CSV), Not provided (GKPG)
Data Type: Time
Multiplicity: [1]
The version number relates to the product schema and not this technical specification.
Version number of the product schema, for example, 1.0, 2.0.
Attribute Name: Not provided (GML), VERSION (CSV), Not provided (GKPG)
Data Type: char
Size: 7
Multiplicity: [1]
States whether the data supply is a full supply or change only supply.
Attribute Name: Not provided (GML), FILE_TYPE (CSV), Not provided (GKPG)
Code List Name: FileTypeCode
Size: 1
Multiplicity: [1]
The header files and product classification scheme for AddressBase Premium are available to download under from the product page here.
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
A code list or enumeration is a controlled set of values which can be used to populate a specific column.
The diagram below shows the code list and enumeration UML model associated with AddressBase Premium with their appropriate descriptions.
The naming of attributes between CSV, GML and GPKG will be different due to the requirements of the file formats. The following tables map the CSV attribute name to the GML and GPKG attribute names.
CSV | GML | GPKG |
---|---|---|
CSV | GML | GKPG |
---|---|---|
CSV | GML | GPKG |
---|---|---|
CSV | GML | GPKG |
---|---|---|
CSV | GML | GPKG |
---|---|---|
CSV | GML | GPKG |
---|---|---|
CSV | GML | GeoPackage |
---|---|---|
CSV | GML | GeoPackage |
---|---|---|
CSV | GML | GeoPackage |
---|---|---|
CSV | GML | GKPG |
---|---|---|
CSV | GML | GKPG |
---|---|---|
RECORD_IDENTIFIER
Not required in GML
Not provided in GeoPackage
CHANGE_TYPE
changeType (Provided in FeatureWithLifecycle)
change_type
PRO_ORDER
Not required in GML
Not provided in GeoPackage
UPRN
uprn
uprn
LOGICAL_STATUS
logicalStatus
logical_status
BLPU_STATE
blpuState
blpu_state
BLPU_STATE_DATE
blpuStateDate
blpu_state_date
PARENT_UPRN
parentUPRN
parent_uprn
X_COORDINATE
position
x_coordinate
Y_COORDINATE
position
y_coordinate
LATITUDE
positionLatLong
latitude
LONGITUDE
positionLatLong
longitude
RPC
rpc
rpc
LOCAL_CUSTODIAN_CODE
localCustodianCode
local_custodian_code
COUNTRY
country
country
START_DATE
startDate (Provided in FeatureWithLifecycle)
start_date
END_DATE
endDate (Provided in FeatureWithLifecycle)
end_date
LAST_UPDATE_DATE
lastUpdateDate (Provided in FeatureWithLifecycle)
last_update_date
ENTRY_DATE
entryDate (Provided in FeatureWithLifecycle)
entry_date
ADDRESSBASE_POSTAL
addressbasePostal
addressbase_postal
POSTCODE_LOCATOR
postcodeLocator
postcode_locator
MULTI_OCC_COUNT
multiOccCount
multi_occ_count
RECORD_IDENTIFIER
Not required in GML
Not provided in GeoPackage
CHANGE_TYPE
Not required in GML
change_type
PRO_ORDER
Not required in GML
Not provided in GeoPackage
URPN
uprn (obtained from the feature)
uprn
CLASS_KEY
classKey
class_key
CLASSIFICATION_CODE
classificationCode
classification_code
CLASS_SCHEME
classScheme
class_scheme
SCHEME_VERSION
schemeVersion
scheme_version
START_DATE
START_DATE (Provided in EntityWithLifecycle)
start_date
END_DATE
Provided in EntityWithLifecycle
end_date
LAST_UPDATE_DATE
Provided in EntityWithLifecycle
last_update_date
ENTRY_DATE
Provided in EntityWithLifecycle
entry_date
RECORD_IDENTIFIER
Not required in GML
Not provided in GKPG
CHANGE_TYPE
Not required in GML
change_type
PRO_ORDER
Not required in GML
Not provided in GKPG
UPRN
uprn (obtained from the feature)
uprn
UDPRN
udprn
udprn
ORGANISATION_NAME
organisationName
organisation_name
DEPARTMENT_NAME
departmentName
department_name
SUB_BUILDING_NAME
subBuildingName
sub_building_name
BUILDING_NAME
buildingName
building_name
BUILDING_NUMBER
buildingNumber
building_number
DEPENDENT_THOROUGHFARE
dependentThoroughfare
dependent_thoroughfare
THOROUGHFARE
thoroughfare
thoroughfare
DOUBLE_DEPENDENT_LOCA LITY
doubleDependentLocality
double_dependent_locality
DEPENDENT_LOCALITY
dependentLocality
dependent_locality
POST_TOWN
postTown
post_town
POSTCODE
postcode
postcode
POSTCODE_TYPE
postcodeType
postcode_type
DELIVERY_POINT_SUFFIX
deliveryPointSuffix
delivery_point_suffix
WELSH_DEPENDENT_THOR OUGHFARE
welshDependentThoroughfare
welsh_dependent_thoroughfare
WELSH_THOROUGHFARE
welshThoroughfare
welsh_thoroughfare
WELSH_DOUBLE_DEPENDEN T_LOCALITY
welshDoubleDependentLocality
welsh_double_dependent_locality
WELSH_DEPENDENT_LOCALI TY
welshDependentLocality
welsh_dependent_locality
WELSH_POST_TOWN
welshPostTown
welsh_post_town
PO_BOX_NUMBER
poBoxNumber
po_box_number
PROCESS_DATE
processDate
process_date
START_DATE
START_DATE (Provided in EntityWithLifecycle)
start_date
END_DATE
Provided in EntityWithLifecycle
end_date
LAST_UPDATE_DATE
Provided in EntityWithLifecycle
last_update_date
ENTRY_DATE
Provided in EntityWithLifecycle
entry_date
RECORD_IDENTIFIER
Not required in GML
Not provided in GPKG
CHANGE_TYPE
Not required in GML
change_type
PRO_ORDER
Not required in GML
Not provided in GPKG
UPRN
uprn (obtained from the feature)
uprn
LPI_KEY
lpiKey
lpi_key
LANGUAGE
Provided within an ‘xml:lang’ tag
language
LOGICAL_STATUS
logicalStatus
logical_status
START_DATE
startDate (Provided in EntityWithLifecycle)
start_date
END_DATE
endDate (Provided in EntityWithLifecycle)
end_date
LAST_UPDATE_DATE
lastUpdateDate (Provided in EntityWithLifecycle)
last_update_date
ENTRY_DATE
entryDate (Provided in EntityWithLifecycle)
entry_date
SAO_START_NUMBER
saoStartNumber
sao_start_number
SAO_START_SUFFIX
saoStartSuffix
sao_start_suffix
SAO_END_NUMBER
saoEndNumber
sao_end_number
SAO_END_SUFFIX
saoEndSuffix
sao_end_suffix
SAO_TEXT
saoText
sao_text
PAO_START_NUMBER
paoStartNumber
pao_start_number
PAO_START_SUFFIX
paoStartSuffix
pao_start_suffix
PAO_END_NUMBER
paoEndNumber
pao_end_number
PAO_END_SUFFIX
paoEndSuffix
pao_end_suffix
PAO_TEXT
paoText
pao_text
USRN
usrn
usrn
USRN_MATCH_INDICATOR
usrnMatchIndicator
usrn_match_indicator
AREA_NAME
areaName
area_name
LEVEL
level
level
OFFICIAL_FLAG
officialFlag
official_flag
RECORD_IDENTIFIER
Not required in GML
Not provided in GPKG
CHANGE_TYPE
Not required in GML
change_type
PRO_ORDER
Not required in GML
Not provided in GPKG
UPRN
uprn (obtained from the feature)
uprn
ORG_KEY
orgKey
org_key
ORGANISATION
organisation
organisation
LEGAL_NAME
legalName
legal_name
START_DATE
startDate (Provided in EntityWithLifecycle)
start_date
END_DATE
endDate (Provided in EntityWithLifecycle)
end_date
LAST_UPDATE_DATE
lastUpdateDate (Provided in EntityWithLifecycle)
last_update_date
ENTRY_DATE
entryDate (Provided in EntityWithLifecycle)
entry_date
RECORD_IDENTIFIER
Not required in GML
Not provided in GPKG
CHANGE_TYPE
Not required in GML
change_type
PRO_ORDER
Not required in GML
Not provided in GPKG
UPRN
uprn (obtained from the feature)
uprn
XREF_KEY
xrefKey
xref_key
CROSS_REFERENCE
crossReference
cross_reference
VERSION
version
version
SOURCE
source
source
START_DATE
startDate (Provided in EntityWithLifecycle)
start_date
END_DATE
endDate (Provided in EntityWithLifecycle)
end_date
LAST_UPDATE_DATE
lastUpdateDate (Provided in EntityWithLifecycle)
last_update_date
ENTRY_DATE
entryDate (Provided in EntityWithLifecycle)
entry_date
RECORD_IDENTIFIER
Not required in GML
Not provided in GeoPackage
CHANGE_TYPE
changeType (Provided in FeatureWithLifecycle)
change_type
PRO_ORDER
Not required in GML
Not provided in GeoPackage
USRN
usrn
usrn
RECORD_TYPE
recordType
record_type
SWA_ORG_REF_NAMING
swaOrgRefNaming
swa_org_ref_naming
STATE
state
state
STATE_DATE
stateDate
state_date
STREET_SURFACE
streetSurface
street_surface
STREET_CLASSIFICATION
streetClassification
street_classification
VERSION
version
version
STREET_START_DATE
startDate (Provided in FeatureWithLifecycle)
street_start_date
STREET_END_DATE
endDate (Provided in FeatureWithLifecycle)
street_end_date
LAST_UPDATE_DATE
lastUpdateDate (Provided in FeatureWithLifecycle)
last_update_date
RECORD_ENTRY_DATE
entryDate (Provided in FeatureWithLifecycle)
record_entry_date
STREET_START_X
streetStart
street_start_x
STREET_START_Y
streetStart
street_start_y
STREET_START_LAT
streetStartLatLong
street_start_lat
STREET_START_LONG
streetStartLatLong
street_start_long
STREET_END_X
streetEnd
street_end_x
STREET_END_Y
streetEnd
street_end_y
STREET_END_LAT
steetEndLatLong
street_end_lat
STREET_END_LONG
steetEndLatLong
street_end_long
STREET_TOLERANCE
streetTolerance
street_tolerance
RECORD_IDENTIFIER
Not required in GML
Not provided in GeoPackage
CHANGE_TYPE
Not required in GML
change_type
PRO_ORDER
Not required in GML
Not provided in GeoPackage
USRN
usrn (obtained from the feature)
usrn
STREET_DESCRIPTION
streetDescription
street_description
LOCALITY
locality
locality
TOWN_NAME
townName
town_name
ADMINSTRATIVE_AREA
administrativeArea
administrative_area
LANGUAGE
Provided within an ‘xml:lang’ tag
language
START_DATE
startDate (Provided in EntityWithLifecycle)
start_date
END_DATE
endDate (Provided in EntityWithLifecycle)
end_date
LAST_UPDATE_DATE
lastUpdateDate (Provided in EntityWithLifecycle)
last_update_date
ENTRY_DATE
entryDate (Provided in EntityWithLifecycle)
entry_date
RECORD_IDENTIFIER
Not required in GML
Not provided in GeoPackage
CHANGE_TYPE
Not required in GML
change_type
PRO_ORDER
Not required in GML
Not provided in GeoPackage
UPRN
uprn
uprn
SUCC_KEY
succKey
succ_key
START_DATE
startDate (Provided in EntityWithLifecycle)
start_date
END_DATE
endDate (Provided in EntityWithLifecycle)
end_date
LAST_UPDATE_DATE
lastUpdateDate (Provided in EntityWithLifecycle)
last_update_date
ENTRY_DATE
entryDate (Provided in EntityWithLifecycle)
entry_date
SUCCESSOR
successor
successor
Provided within the datatypes
startDate
Provided within the datatypes
Provided within the datatypes
endDate
Provided within the datatypes
Provided within the datatypes
lastUpdateDate
Provided within the datatypes
Provided within the datatypes
entryDate
Provided within the datatypes
Provided within the feature type
changeType
Provided within the feature type
Provided within the feature type
startDate
Provided within the feature type
Provided within the feature type
endDate
Provided within the feature type
Provided within the feature type
lastUpdateDate
Provided within the feature type
Provided within the feature type
entryDate
Provided within the feature type