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.

AddressBase products do not have an Ordnance Survey ADDRESS-POINT Reference Number OSAPR, why?

In the new AddressBase products we have introduced the Unique Property Reference Number (UPRN) which is assigned at address creation and persists throughout the address lifecycle (creation to historic).  In creating the best content for the new products there have been some elements from the existing products that will no longer be included, such as the OSAPR. This is a unique identifier that Ordnance Survey assigned when we processed the PAF data and create the ADDRESS-POINT product, which flows through into the OS MasterMap address products. With the inclusion of the UPRN there is no benefit in having many unique references for a similar use and when ADDRESS-POINT is eventually withdrawn we will no longer be generating OSAPR’s. During the product development consultation period this removal was discussed and although concerns were raised it has been accepted that there is a migration solution. This will be in the form of a cross reference look up between existing OSAPR’s to the UPRN, to align information attached to the OSAPR to the URPN which will be used for those engaging in a migration process.

How will AddressBase COU files be supplied?

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

The file naming convention will be as follows:

CSV

• AddressBase Premium will be AddressBasePremium_Date_Filenumber.csv
• AddressBase Plus will be AddressBasePlus_Date_Filenumber.csv
• AddressBase will be AddressBase_Date_Filenumber.csv

GML

• AddressBase Premium will be AddressBasePremium_Date_Filenumber.gml
• AddressBase Plus will be AddressBasePlus_Date_Filenumber.gml
• AddressBase will be AddressBase_Filenumber.gml

Zipped folders will be

CSV

• AddressBase Premium will be AddressBasePremium_COU_Date_Filenumber_csv.zip
• AddressBase Plus will be AddressBasePlus_COU_Date_Filenumber_csv.zip
• AddressBase will be AddressBase_COU_Date_Filenumber_csv.zip

GML

• AddressBase Premium will be AddressBasePremium_COU_Date_Filenumber_gml.zip
• AddressBase Plus will be AddressBasePlus_COU_Date_Filenumber_gml.zip
• AddressBase will be AddressBase_Date_COU_Filenumber_gml.zip

All Filenumbers will be to a precision of 3 with padded 0’s if required e.g. 7 will be AddressBasePremium_FULL_03-08-2011_007_gml.zip

How will change versioning be managed in the AddressBase Products?

On a product level, change versioning is managed in accordance with the cyclic naming convention specified with each six weekly product release; e.g. AddressBase Release 1; 2011

On a feature level, change versioning is managed by the following fields:

Note: This field will always be ‘I’ (Insert) in the full supply of the product.   
The Change Only Update supply will utilise the ‘U’ (Update) and ‘D’ (Delete) values.

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

Yes.  Customers working with the same version of the same product (e.g. AddressBase) will have exactly the same information.
Where however, customers are using different AddressBase products it is possible that in a small number of cases some of them will either:

1) Not have an address (such as between AddressBase and AddressBase Plus

2) The attributes of an address may differ (i.e. detail of the classifications- primary to quaternary)

3) This situation may arise because the AddressBase product range offers customers 3 levels of content and completeness.

Because AddressBase Premium has more complete addressing information (e.g. Provisional, Historical and Alternative addresses)

4) Inherent in each AddressBase product, there are subtle differences in the lifecycle of an address based on the refresh cycles of the input sources.  Royal Mail publishes their PAF on a monthly basis whereas Local Authorities can update the GeoPlace data hub on a daily basis.  This means that the AddressBase product can become temporarily out of step with the other two products in the event of the AddressBase product release not synchronising with the PAF publish date.

Furthermore, the AddressBase Premium product retains historical information about addresses that have ceased to exist in the real world.  So a newly demolished address can (for a short time) appear differently in all three specifications.  The table below demonstrates this.

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 – Dataset ID “MT” and OS MasterMap Integrated Transport Network – Dataset ID “MI”).

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 a 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 AddressBase because the fields used to create a concatenated address are often dependent on each customer’s individual requirements. However, because AddressBase is supplied as raw data, customers can create their own concatenated addresses based on the information within AddressBase 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” (Is an multiple residency address e.g. a flat behind an official address) and “M” (This is a delivery address with at least one child a BLPU that receives 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

UPRN:10000001

PAO_TEXT: Duffield House

POSTAL_ADDRESS: M

            Child 1 BLPU

            UPRN:10000002

            PARENT_UPRN: 10000001

            PAO_TEXT: Duffield House

            SAO_START_NUMBER: 1

POSTAL_ADDRESS: C

Child 2 BLPU

            UPRN:10000003

            PARENT_UPRN: 10000001

            PAO_TEXT: Duffield House

            SAO_START_NUMBER: 2

            POSTAL_ADDRESS: C

 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

What is the difference between the POSTCODE and POSTCODE_LOCATOR fields in AddressBase Plus and Premium?

The Postcode and Postcode locator fields essentially look the same. The difference between them is tied into the source data used to populate the fields.

The POSTCODE field is the Royal Mail Postcode taken from the RM PAF (Postal Address File) supply used to create the product. 

The POSTCODE_LOCATOR field relates to the geographic address.  It is derived by spatially matching the AddressBase products coordinate with the last quarterly release of Code-Point® with polygons.  

The values in the Postcode and Postcode_locator field are the same in the majority of cases.

Why are the values in these fields occasionally different?

1) The AddressBase products coordinate pair may not be in its final position. 

Because the postcode_locator value is derived spatially the coordinate will dictate the postcode_locator value.  It is therefore very important to use the field in conjunction with the RPC (Representative Point Code) which indicates the positional quality of the coordinates and therefore the accuracy of the postcode_locator value.   

2) Different update cycles

Codepoint with Polygons is supplied quarterly.  PAF is supplied monthly.  This means that if there’s a postcode change in PAF the postcode won’t appear in Codepoint with Polygons until the next refresh of that product.  When it is refreshed, the Postcode_Locator field will be updated with the next refresh of the AddressBase products.

3) The postcode_locator is a ‘Vertical street’

A vertical street is defined in Codepoint with polygons as

Where two or more postcodes are associated with a single building seed, a single distinctive square polygon will represent all the postcodes attached to the seed. These polygons have a special series of identifiers, all commencing with the letter V.

Please see the screenshot below of UPRN 100062365707 with Codepoint with Polygons and OS MasterMap Topography layer overlaid.

Figure 2: The red square is the vertical street that UPRN 100062365707 is positioned in.

The rules for population of the postcode_locator field where the address is in a vertical street is to alpha numerically sort the postcodes associated to the vertical street and choose the first postcode entry from the list.

This may mean that the postcode that is used to populate the postcode_locator field is different to the PAF address that the UPRN has been matched to within the vertical street therefore resulting in a difference.

Which one should I use?

This depends on your business requirement.  The general guidance is:

If the Royal Mail delivery point is your preference use the Postcode field.  If a Postcode is not present or if your preference is for geographic addresses; use the Postcode_locator field in conjunction with the RPC value to get an indicative postcode.

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

Following reasons that PAF may not make it into 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 PAF.
3. Mismatches: Local Authority addresses may be depicted differently in PAF.  For example a Local Authority addresses may legally 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.