Software designed to read and reformat service charge statements sent to homeowners on Cressingham Gardens Estate (CGE), a residential housing estate in the London Borough of Lambeth, South London. CGE currently faces demolition by Lambeth’s regeneration department who argue it is too costly for repair. The code employs computer vision technologies to convert a .pdf document to a series of images, identify and extract repairs data, then convert jobs to a .csv formated file. The generated .csv file allows residents to more easily coordinate efforts to contest repairs data. This script exposes underlying data structures and socio-technical process involved in the management of Lambeth’s housing. It also provides space to speculate how all residents of Lambeth’s housing estates might be engaged in contesting repairs data and regenerative processes.
Simplified extract from “AtYourService.py” python script
Parsing the service charge exposes the operations of the relational database. Partial datasets are presented. Job numbers without SOR codes so its impossible to re-create or interigate repairs statements against council invoices.
I the script revealed colums of data that had not been added up correctly, and inconsistant ‘ratable values’ from year to year. One can only speculate if these errors are due to errors in code, human error, a shift in organisationla structure [Lambeth living], or simply a misunderstanding on my part. I can only highlight my concerns to Lambeth officers and hoope they satisfactorally explain.
The script has triggered further FOI requests (rateable values)… Ratable values are a supposidly simple calculation, where each property within a block could potentially pay a different amount. [legislation, new datasets]
Also revealed differnces in design and print where each year contains subtle differences in layout, requiring me to programm new sub-routines to accouint for the changes.
Acting at a distance.
The size of the resulatant spreadsheet caused me to alter an arrangement of fields of data so I was more easily able to compare job descriptions with cost and date headings. This prompted a refactoring of code, the script and I collectivly negotiate new forms of .csv file where at times it becomes unclear who or wjhat makes the decisive decision.
It is difficult to see how a council offcier could intergiate the data as effictivly as a resident who has an intuitive understanding.
SPlit database systems… SOR codes… Attemting to make a JOIN stament accross databases that don’t appear to be linked [REF finance tim who said we were asking different questions which made them work differently]