What is it and how you can use it
We have created an infographic that provides a graphical ‘snapshot’ of how well integrated core systems within your authority are with the Unique Street Reference Number (USRN).
The infographic can be used for whatever purpose you like such as:
highlighting which departments / suppliers to engage with to improve integration
a tool to show senior management how well integrated the USRN is
a tool to gain buy-in from senior management / other teams to assist with integrating with the USRN
identifying specific areas to focus on to improve integration
What information has been used to create this?
The infographic utilises your responses to the Streets Improvement Schedule Questionnaire 2024/25. It draws on the information submitted specifically around system integrations to create the visuals that you see.
What systems are included?
There are 12 key systems represented in the infographic as listed on the left.
What information does the infographic show?
For each system listed, the infographic displays a colour-coded system (red, amber green) using a series of 3 hexagons (inner, middle, outer). These depict measures across 3x areas as captured within the Improvement Schedule questionnaire.
Measure 1: the system’s reliance on the USRN (inner hexagon)
Measure 2: the street data currency within the system (middle hexagon)
Measure 3: the method used to update the system with street data (outer hexagon)
A national average for each measure is calculated to provide context on how you compare to other authorities at a national level (maximum score is 10).
An indicator icon denotes whether or not you are above this (green arrow), achieving the national average (amber circle) or below the national average (red arrow).
In addition, an "overall integration score" is featured which provides a single figure for comparison. This is an average of the 3x integration measures and is also accompanied by an indicator icon denoting its position in relation to the national average.
Measure 1: System reliance on the USRN
What do we mean by "reliance"? The ability of the software system to solely rely on the USRN and definitive street names and not permit the entry of manual, unvalidated street names.
What to aim for: Software systems which mandate the usage of the USRN and implement a lookup drawing “official street names" from a definitive source.
Further guidance on definitive data sources can be found in the below guide:
Why reliance on the USRN is important:
How you can improve :
Determine if the software system can utilise address data and the USRN and mandate its use. You may need to ask your I.T dept or system supplier directly.
A list of key questions can be found in the below guide which can help you determine what is possible:
If manually entered streets are present and permitted, then they will need to be periodically matched to a USRN and retrospectively updated and corrected in the system if required. This is key to ensuring street data remains trustworthy and accurate.
Further guidance on dealing with manually entered street information can be found in the below guides:
Measure 2: Currency of street data
What do we mean by "currency"? How frequently street data is updated and kept current in the system
What to aim for: Street data should be updated as frequently as possible in departmental systems in order to support their day-to-day tasks and functions.
This could mean weekly or monthly frequencies in line with the published version of the National Street Gazetteer, but in some cases real-time if your LSG is part of a wider street and asset management system. Knowing how current the data should be all depends on what the service area requires. The answer to this question involves discussing their street data requirements with them.
Why currency of data is so important:
How you can improve:
Speak with the department that owns the system and determine how frequently they require street data to be updated. A key question could be to ask them:
"What is the longest amount of time you are prepared to wait for new street information to be added to the system?"
Determine how frequently the system can actually load and consume street data. You may need to ask your I.T dept or the system supplier directly to obtain this answer.
A list of key questions can be found in the below guide which can help you determine what is possible:
Once you know the department's requirements, plus the capability of the system (how frequently it can load street data), then the next step is to ensure that you are using the correct data product which supports that currency.
Further guidance on definitive data sources can be found in the below guide:
Aim to implement the most frequent option possible to support the department's service needs.
Measure 3: Method of update
What do we mean by "method" of update? How automated the mechanism is to update street data and the USRN within the consuming software system.
What to aim for: As automated and “hands off” as possible
Why is "method" of update important?
How you can improve
Suppliers often utilise one of the below "methods" of update but may support others:
Method of Update | Details | Desirability / Automation |
|---|---|---|
Manual entry | Relies on streets being inserted and updated manually one-by-one with their USRN. | Lowest |
Custom, bespoke processes | The authority's own developed processes such as scripts and scheduled tasks on a server to load street data. | Low |
Suppliers own utility / loader | A specific utility or module created by the supplier requiring manual usage to load street data. | Moderate |
DB link / API | System is capable of consuming street data via an API such as the GeoPlace DataVia API or a live link to the LSG database. Requires no manual intervention. | Highest |
Determine what method of update the software system currently uses to load street data and also those methods which the supplier can also support (such as consuming a street data API). You may need to ask your I.T. dept or system supplier directly.
A list of key questions can be found in the below guide which can help you determine what is possible:
Aim to implement the most automated, "desirable" option possible (indicated in the table above).
How the scores are calculated
Scores for the 3x integration measures listed below are calculated in 3 steps.
Measure 1: System reliance on the USRN (maximum score of 10)
Measure 2: Street data currency (maximum score of 10)
Measure 3: Method of update (maximum score of 10)
Step 1:
Responses to the improvement schedule questionnaire are categorised and scored on a scale of 0 – 10.
0 = Immediate improvement required
For example:
“System is not reliant on the USRN in any way”
“Currency of data is very low or not updated”
“Method of update is manual or not updated”
10 = Best possible response
For example:
“System is completely reliant on the USRN”
“Currency of data is the highest it can be (real-time)”
“Method of update is via DB link / API”
Step 2:
The total “score” for each of the 3x measures across all systems or services which are provided by the authority is calculated.
Systems and services that are marked as “Service not provided” are excluded.
Step 3:
The respective total for each measure is divided by the number of systems /
The figure is denoted to 1 decimal place and rounded up to obtain the “score” for the specific measure.
The maximum score that can be obtained is 10.
Calculation of the “Overall Integration Score”
This is simply the average of the scores for the 3x measures.
The overall figure is denoted to 1 decimal place and rounded up.
The maximum score that can be obtained is 10.
Calculation of the “National Averages”
A national average for each of the 3x measures is calculated to provide context to each authority on how they compare to others at a national level. These are:
National average Integration score
National average score for “System reliance on the USRN”
National average score for “Street data currency”
National average score for “Method of update”
The “National average” is the average of all local authority scores for each respective measure, denoted to 1 decimal place.