Collaborative approach to improving data accuracy and quality in Durham

Durham developed bespoke scripts which they have shared with the wider DCA street community to respond to some of the additional data quality requests. This community focus of the way Durham have approached problems rightly deserves this highly commended Award.

GeoPlace’s new Street Gazetteer Health Checks for 2022-23 introduced SR101 to the Indicator levels in Street Health Check 2. When the team tried to resolve errors, it was found that the Street Gazetteer software was exporting Type 1/2 coordinates on Type 11 (Addressing Only) streets on ESUs. It wasn’t possible to get the Gazetteer software to export the correct coordinates for the ESU, without changing the street type from Addressing Level.

To resolve the problem, a program was written in Python that would let not only Durham County Council but any Street Gazetteer Custodian with the same issue to amend their data output with the correct coordinates. Compliance checks were run on the input data, ensuring it matches with GeoPlace data standards. The addition of the correct coordinates for addressing only streets helps to ensure data accuracy and quality of the Street Gazetteer.

The challenges

With the introduction of the new Street Gazetteer health checks for 2022-23 and the pre-benchmark scores released late 2021, the team had been looking at how to improve Street Gazetteer scores, not only in Criteria, but in Indicators too.

As the team worked through the new checks in Street Health Check 2, it was noticed that for the SR101 check, several of the streets listed with conflicting coordinates were Alias streets (Type 11 record – Addressing Only, assigned to an ESU). The coordinates exporting from the infrastructure management/Gazetteer software were also those of the parent street (Type 1 or 2). It wasn’t possible to resolve this with the software provider. But it was also noted that other Street Gazetteer custodians were in a similar position. This meant that data was being imported inaccurately, with Custodians being unable to prevent this.

The solution

A small program was written in Python to fix these errors: replacing the parent street coordinates in the exported .csv file with user specified coordinates and adding them to a check list, so that when the coordinates for the alias streets are recorded in the check list, the task of amending them would not be an onerous one. All that would be needed, would be to copy the xxxx_LG.csv file in the folder with the program, click the executable file and add in the HA code (on each export).

The program performs multiple checks on the data output from it. It does not amend the record if the data in the SR101 Check file row is incorrect (e.g., nonstandard NSG Ref, Coordinates, empty coordinate cells). Multiple checks were done on the output (including on uploads to GeoPlace (Test and Live)), which passed validation, and in the Street Health Check to ensure the SR101 errors were corrected.

A link to the software was then posted on LinkedIn, and shared with the Northeast England Street Gazetteer Custodians Chair, Stephen Black. The software was then made available to other Street Gazetteer custodians experiencing the same challenge.

The results

The program allows the amendment of the Addressing Only Type 11 Streets, which was previously not possible through the Street Gazetteer management software provider. The distribution of the software allows any Gazetteer Custodian, experiencing the same issues with the SR101 health check in Street Health Check 2 for 2022-23, to make amendments to correct their output data, ensuring better data accuracy and quality. The program also allows the amendment of SPSR003 errors, which follow a similar pattern of export issues.