A multitude of choice
There is a wide range of address data products available to you when considering integrating with a system. Your Local Land and Property Gazetteer (LLPG) is of course one of these.
These address data products are provided by Ordnance Survey (OS) under the Public Sector Geospatial Agreement (PSGA) and are free to local authorities. Each has their own characteristics such as varying:
Update cycle / currency
File formats / mechanism of delivery e.g. API
Classification types
Lifecycle information (Approved, Provisional, Alternative, Historical)
Links to Royal Mail PAF / VOA data
Geographic coverage
All of these products contain the UPRN and include the official address created by local authorities (except for the "AddressBase" dataset which contains the Royal Mail PAF address only).
Accessing the data
You can access data under the PSGA via the OS Data Hub, although you will require a login account linked to your authority. Your PSGA Principal Contact will have further details on how to access and set this up so please speak with them. If you do not know who this is in your organisation, then contact OS.
Comparing the data products and their differences
Ordnance Survey has put together comprehensive documentation outlining all of the products in their address data portfolio as listed below.
The documentation highlights the various differences between each address data product to help make it easier for you to choose the most applicable for your specific need.
Your Local Land and Property Gazetteer (LLPG) is also a dataset which should be factored into this comparison. For this dataset, the Authority Address Custodian controls the frequency of update for consuming systems (through DTF exports) and also its currency (how often the data is modified).
APIs versus File based integration
Integration using APIs represent the most efficient, robust and error-free methods of integrating address data as compared to file-based integrations (those utilising Change Only Update (CoU) files or full exports).
APIs such as the OS Places API allows address data to be directly integrated with the software system, needing to only configure once in a truly "set-and-forget" approach.
Updates to the source address data are automatically reflected meaning there is no need to process change only updates or conduct refreshes, saving considerable time in administration and error processing.
The main question here is whether or not your supplier can consume the OS Places API and this needs to be raised with them to find out what is technically possible and if not, what other data products and formats they support.
Choosing a data source to integrate with
Key considerations
Trying to determine what the best data source to select is can be quite daunting, however our Procurement Statement Tool can help you identify some of the key questions you need to consider to integrate with a departmental system.
Whilst the tool is focused on generating procurement criteria statements, it asks fundamental questions about the requirements of the department who owns the system.
Ultimately it will be them who will use the address data so selecting a source which supports them to deliver their services effectively is crucial.
Gathering departmental data requirements: Key questions
Q1 | Frequency of supply What is the longest amount of time the department is prepared to wait for addresses to be updated or added to the system? The answer to this question will help determine which data product to select. The selection must have a currency no greater than what the department requires. For example if the department requires weekly updates, then a dataset with a monthly currency is not fit for purpose. |
Q2 | Geographic coverage Are out-of-authority addresses required? |
Q3 | Type of records - Lifecycle Address data contains properties at different points of its "lifecycle" (BLPU State), for example:
Are specific lifecycle (BLPU States) required or not required? |
Q4 | Type of records - multiplicity Address data can contain multiple representations of the same property through the use of Land and Property Identifiers (LPIs). A property can have multiple LPIs all tied to the same UPRN creating a one-to-many (UPRN to LPI) relationship. As well as "Approved" LPIs, does the service area need to see any of the following in their system? - "Alternative" LPIs - "Provisional" LPIs - "Historical" LPIs - Bilingual LPIs |
Q5 | Type of records - Classifications Are all property types (classifications) required, or should some be filtered out within the system, such as (and not limited to): -Roundabouts -ATMs -Parks -Advertising hoardings -"STREET RECORDS" -"Parent Shells" |
Q6 | API support Can the software support integration with the OS Places API or can it only consume file-based updates? |
The answers to the above questions should help whittle down what address data product is best for you to choose.