Jump to the following:

We use cookies to improve this website. Read about cookies

AddressBase technical FAQs

What is a UPRN?

A Unique Property Reference Number (UPRN) is the persistent unique identifier that underpins the AddressBase products range.

Each record has a UPRN which provides a reference key to join related address records across different datasets.

Throughout its lifecycle, information on the address of a property can change. This may be due to a change of name, a sub-division or aggregation of an address within a building, change of use, such as from single occupancy to multiple occupancy or the eventual demolition of the property. All of these historic, alternative and provisional addresses are recorded against the same UPRN.

UPRNs are integers (numbers) that can be up to 12 digits in length; they can therefore be less than 12 digits long and do not require leading zeros. However some gazetteer database applications will pad UPRNs that are less than 12 digits with zeros.

What is a change only update (COU) supply of the AddressBase products?

A change only update (COU) supply of data contains records or files that have changed between product refreshes to a customer.

COU data enables a user to identify three types of change:

1) Inserts (CHANGE_TYPE ‘I’) are objects that have been newly inserted into your area of interest since the last product refresh.

2) Deletes (CHANGE_TYPE ‘D’) are objects that have ceased to exist in your area of interest since the last product refresh.

3) Updates (CHANGE_TYPE ‘U’) are objects that have been updated in your area of interest since the last product refresh.

Will the COU change type be the same for an address that has been updated in all of the AddressBase products?

Not necessarily. In the main, if an address that exists in all 3 products has changed the COU will be reflected consistently (where the change is within each respective technical specification). However, because AddressBase contains only PAF matched addresses and AddressBase Premium contains provisional and historic records it is possible that COU CHANGE_TYPEs will differ between products.

For example, if a house is under construction, the address of this house (when known) may be created in AddressBase Premium as a ‘provisional address’. This would be reflected as a COU CHANGE_TYPE of ‘I’ because it is being inserted into this product for the first time. This address would not appear in the COU for AddressBase or AddressBase Plus because these products only contain the current ‘approved’ addresses. When the construction of the house is completed and the status of the address is set to ‘approved’ it is only then that the COU for AddressBase Plus will capture this change as a CHANGE_TYPE ‘I’. In AddressBase Premium this address change would be reflected as a ‘U’ in AddressBase Premium because an existing record is being updated. When the Local Authority address is matched to the appropriate PAF address this address will be entered in the AddressBase product for the first time with a CHANGE_TYPE ‘I’. AddressBase Plus would reflect the inclusion of the PAF address as a ‘U’ because an existing record is being updated whilst AddressBase Premium would have a new DPA table with a CHANGE_TYPE ‘I’.

Likewise, if an address is demolished in the real world there is no longer a requirement to manage the address as the current address. Therefore, in AddressBase and AddressBase Plus this record will have a change type of ‘D’ and will be deleted from your data holdings when applied. In AddressBase Premium however, the change type for this record will be ‘U’ because a status attribute is updated to reflect that it is a historic record.What benefit will I receive if I take a COU refresh of the product over a full supply refresh?

The benefit of receiving your product as a COU supply is that data volumes are smaller therefore it will significantly reduce the amount of time required to process each product refresh of the data when compared to the time taken to process a full supply. This means that the most up to date AddressBase products content will be available to you quicker.

COU supply is most effective when applied every time that the product is refreshed. For example, AddressBase products are refreshed every six weeks (as full supply and COU). Therefore to ensure that your data holdings are complete and consistent with the full supply, you should request and apply COU for your area of interest every six weeks.

AddressBase products refresh (epoch) dates are available here.

What does ‘base-lining my data’ mean?

‘Base-lining’ is preparing your data holdings with the most up-to-date full supply of the product before applying change only update for the first time.

If you have previously been supplied your product data as a full supply it is important that before you apply a COU to your data holdings you ensure that your data holdings are up-to-date. For example, if you intend to apply COU for the first time using Epoch 17 COU, you must ensure that the Epoch 16 Full Supply is loaded as a baseline in your data holdings. If this isn’t the case and you apply Epoch 17 COU to Epoch 15 Full Supply you may lose some important changes and corrupt your data holdings.

How will AddressBase products Change Only Update (COU) files be supplied?

The data is delivered in one of two methods:

  1. Non geographic chunks (containing up to 1 million changes within csv or 200,000 features in GML)
  2. Geographic chunks (5km x 5km ‘tiles’). This option only applies to PSMA customers.

Customers may request updates of the latest changes in their order area at any time using the Ordnance Survey online service. Customers can assign a regular date for receipt of COU. These will then be sent automatically on the required media or placed on the file transfer protocol (FTP) server for collection (if under 2GB). PSMA users can download their geographic chunked COU in the same way that they download the full supply geographic chunks.

Are there any differences between CSV and GML COU?

The addresses contained in the COU for the CSV and GML product formats are exactly the same. However, because the data is structured differently, there are subtle differences in the way feature lifecycles are captured in AddressBase Premium.

AddressBase Premium CSV contains lifecycle information (e.g. last_update_date) for all of the record identifiers (excluding header, trailer and metadata). This granular view of change brings with it a real advantage if your business has a requirement to understand the nature of the change. For example, if you have an interest in seeing how many ‘Commercial’ properties have been updated to ‘Residential’ you can extract this information out from your data holdings using date ranges.

AddressBase Premium GML contains lifecycle information for the BLPU member and the Street member. The BLPU member contains the following address elements: LPI, Classification, Delivery Point Address, Application Cross Reference, Organisation and Successor. The Street member contains the Street and Street Descriptor elements. By structuring the data within these 2 members the user will benefit by being able to load an address into many commonly used applications without the need for translation. This means the data can be used for more than just a transfer format and be implemented in its raw format.

I license an AddressBase product under the Public Sector Agreements, is COU available as tiles?

Yes. Public Sector users can order COU as geographic chunks (5km x 5km tiles). This data is currently available via the download service. COU supplied via this mechanism is ‘tile-based’ COU rather than ‘feature-based’. This means that if an address has changed, the entire tile will be supplied (including unchanged addresses that fall in that tile).

Will all users of the AddressBase products be working with the same data at the same time?

Customers working with the same version of the same product (e.g. both working with ‘Epoch 14’ AddressBase Plus) will have exactly the same information.

Where however, customers are using different AddressBase products the following reasons may affect their ability to share the same data:

1) The product specification may make provision for more attribute granularity in one product over another. For example, AddressBase only contains the primary level of classification (e.g. ‘R’) whereas Plus and Premium can contain up to 4 levels of classification for the same feature (e.g. ‘RD06’).

2) The AddressBase products range offers customers 3 levels of content and completeness.

This may mean that users of different products may not be able to share addresses.

Examples of this include:

AddressBase only contains PAF matched addresses (circa 27.4 million).

AddressBase Plus contains the current approved Local Authority Addresses (circa 33 million) and the PAF equivalent (where present).

AddressBase Premium contains Local Authority information for the complete lifecycle of the address (e.g. Provisional, Historical and Alternative addresses) and the PAF equivalent (where present).

What languages will be available in the AddressBase?

AddressBase products are primarily available in English (ENG) however it provides Welsh (CYM) and Gaelic (GAE) language wherever the source information is available.

Previous OSMM Address products contained the OSMM Topography and OSMM ITN TOID references are these still present?

Yes these are both available in AddressBase Premium and AddressBase Plus products.

The AddressBase Premium product makes them available through the Application Cross Reference Table (OS MasterMap Topography Layer – SOURCE “7666MT” and OS MasterMap Integrated Transport Network – SOURCE “7666MI”). The TOID reference itself is contained in the CROSS_REFERENCE field.

Both references are included in the AddressBase Plus product together with information about the TOID version.

Are the new classifications available and is there a charge?

Yes we have made a freely available AddressBase products Classification look up document located on the Ordnance Survey AddressBase products website pages.

What is the difference in the data formats are the new products available in?

AddressBase products are available as either Comma Separated Value (CSV) or Geographic Markup Language (GML). It will be transferred using a Unicode character set (UTF-8) including ISO-8859-14 (Welsh characters)

CSV format

Comma Separated Values (CSV) format means that the information is supplied in a form where each piece of data is separated from the next by a comma (,).

For example:

100100077917,4201646,"I",,,"R",,316348,177163,1,6815,2001-05-10,,2007-08-29,2001-05-10,"","","","","","",,"",,"","","",166,"",,"","","",5801201,"1","","","","osgb1000002283010753",12,"osgb4000000021638865",5,"osgb1000027126870",3,214788192,,"LLANDAFF ROAD","LLANDAFF ROAD","","LLANDAFF ROAD","","LLANDAFF ROAD","","","PONTCANNA","","","CARDIFF","CARDIFF","CARDIFF","CF11 9PX","CF11 9PX","S","S","","00PTPG","",2011-07-19,0,"","","BIL"

This is also referred to as comma separated variable or Comma Delimited Files (CDF). These files can be opened with spreadsheet applications, databases or translated for use in Geographic Information Systems.

GML format

GML was developed by the Open GIS Consortium (OGC), a global organisation of developers and users that aims to maximise the benefit of geographic information. GML is a spatially enabled dialect of XML schema. According to the World Wide Web Consortium (W3C), XML schemas express shared vocabularies and allow machines to carry out rules made by people. They provide a means for defining the structure, content and semantics of XML documents.

AddressBase is available in GML 3.2.1.

Version 3.2.1 OpenGIS Geography Markup Language (GML) Encoding Standard

AddressBase XML schema is based on http://schemas.opengis.net/gml/3.2.1/gml.xsd

Following a schema ensures a level of standardisation. Standardisation encourages compatibility between different sources of data. GML can therefore be considered as a worldwide standard language for the production and distribution of geographic data.

Will a concatenated address format be available in AddressBase for mailshots?

This format is not currently available for the AddressBase products because the fields used to create a concatenated address are often dependent on each customer’s individual requirements. However, because AddressBase products are supplied as raw data, customers can create their own concatenated addresses based on the information within the AddressBase products for use as mailshots, ERP, SAP systems, etc.

Why do OWPA addresses have a postcode when, by Royal Mail definition they should not have a postcode?

Objects Without Postal Addresses (OWPAs) are assigned a postcode within AddressBase Plus and Premium because a postcode is seen as a vital attribute by a large number of our customers. For example, a number of users including emergency services wish to collate information on events by postcode.

What is the Postal Address flag for?

The POSTAL_ADDRESS flag is a simple flag that indicates which records can have mail sent to them (i.e. a First Floor Flat can, a footbridge cannot. The POSTAL_ADDRESS codes are “S” (Single address); “N” (Not a postal address); “C” (This is a multiple-occupancy or ‘child’ address, for example, a flat behind a parent address.) and “M” (This is a ‘parent’ address with at least one child or associated address that may receive post, for example, 56 the High Street with flat 56a and 56b behind it.).

How will multiple occupancy properties be shown in AddressBase?

The AddressBase Premium and AddressBase Plus products both contain information about properties that have more than one address within them (multiple occupancy properties).

Two factors affect the way that properties that have more than one address within them s are shown in AddressBase Premium or Plus

1 – The Real world Scenario.

2 – The AddressBase Plus or Premium product that you receive

1 – The Real world Scenario. To account for a range of different addressing scenarios in the real world, the rules regarding how multiple occupancy properties are shown in the AddressBase Premium or Plus products depends on the scenario.

As a general rule; multiple occupancy addresses with a shared entrance are shown within AddressBase Premium or Plus products as a structured Parent and Child hierarchy. E.g. take a block of flats with a shared entrance. The property shell (the block) is the ‘parent’ BLPU; and the flats within will each have their own ‘child’ BLPUs with different UPRNs that link to the ‘parent’ via the ‘PARENT_UPRN’ field.

Each BLPU (including the parent) will have a Land and Property Identifier (LPI) that describes the address associated to it.

The LPI belonging to the Parent will be described in one of the Primary Addressable Object (PAO) fields. For example, ‘Duffield House’ would be described in the PAO_TEXT field because it is a text string. Each of the LPIs belonging to the children will be described in their respective Second Addressable Object (SAO) fields, with each of their PAO fields referencing the parent’s PAO_TEXT

A POSTAL_ADDRESS flag is attached to each BLPU. This indicates whether the each address is postally addressable. In the example above the POSTAL_ADDRESS flag will have a value of ‘M’ denoting that this is a delivery address with at least one child BLPU that receives post. Each child that receives post will have a POSTAL_ADDRESS flag of ‘C’ denoting that it is a multiple occupancy address.

Therefore Flat 1 and Flat 2, Duffield House would be attributed as:

Parent BLPU


PAO_TEXT: Duffield House


Child 1 BLPU


PARENT_UPRN: 10000001

PAO_TEXT: Duffield House



Child 2 BLPU


PARENT_UPRN: 10000001

PAO_TEXT: Duffield House



2 – The AddressBase Premium or Plus product you receive will affect which multiple occupancy properties will be shown.

The AddressBase Premium product provides more information about the multiple occupancy property than the AddressBase Plus specification because provisional (planned) and historical (archived) address information is maintained against the property as well as the current address information.

AddressBase Plus only contains information about current multiple occupancy addresses. It also has a MULTI_OCC_COUNT field. This indicates the number of premises served by a single delivery point, for example, flats within a house that the postman cannot ordinarily access. This attribute is only provided where the number of premises is greater than one; that is more premises than just the household at the delivery point.

Note:- The MULTI_OCC_COUNT is not the Royal Mails multi-occ count, it is a number calculated from the number of children linked back to a parent.

AddressBase does not contain multiple occupancy addresses (unless where included with the Royal Mail Postcode Address File).

How do I load the AddressBase products?

You can find instructions on how to load AddressBase Premium, AddressBase Plus and AddressBase in the Getting Started Guide located on the AddressBase Products web pages.

Alternatively, contact our Customer Service Centre.

Why does my address exist in PAF, but not in the AddressBase products?

The following are reasons that PAF may not make it into the AddressBase products:

  1. Missed Epoch creation – This depends on the release schedule of the AddressBase products. If the Epoch generation starts on the 20th of the month and PAF is released on the 19th there is not enough time to get the PAF match results verified and into the product. This is why the version of PAF can vary by up to a month to get into product.
  2. Missing: There are items in PAF that do not exist anymore in the real world, so we have nothing to match it to. These need to be fed back to Royal Mail for them to act upon and rectify in PAF.
  3. Mismatches: Local Authority addresses may be depicted differently in PAF. For example a Local Authority may number a group of flats 1, 2, 3 and 4 however the PAF address may show them as flats A, B, C and D. These you would assume are the same. Quite often we will find flats 1, 2, 3 and 4 in the AddressBase products and flats B, C and D in PAF. Is flat B from the PAF matched to flat 1 or 2 in the AddressBase products? These need to be verified on the ground and sent back to the relevant source to update their core data.
  4. One-to-many matches: In PAF we find that because this is derived for the sole purpose of deliveries there can be some anomalies that make sense to delivery but not for other purposes. Departments are a prime example. Within PAF a department that is a large user of mail can have its own mailing address. However in the AddressBase products we only have one address for that property. We will match the address to the building however the departments or sub addresses from PAF will not make their way into the AddressBase products, however the main BLPU will be matched (where we can find an appropriate match).
  5. Split: This is where a property has split in the AddressBase products and PAF has not caught up. It would not make sense to have a single PAF record to multiple addresses. This needs to be sent back to the relevant source to rectify their data.
  6. Mergers: This is where two (or more) properties have merged in the AddressBase products and PAF has not caught up. We cannot attach multiple PAF records to one address as there is no mechanism for determining which one is the primary address and would cause confusion if you were trying to bill or write to an address. This needs to be sent back to the relevant source to rectify their data.
  7. Multi occupancy: these are technically residential addresses in NLPG- included in the explanation for splits and merges, but slightly different as there is no direct PAF match.
Back to top
© Ordnance Survey 2016
Be sure to take a look at our Terms of Use and Privacy Policy