FOI release
Academic Inquiry: Data Precision Loss and Field Interpretations in LFB Open Data
Case reference FOI2026/00681
Received 11 June 2026
Published 9 July 2026
Request
I am a postgraduate student majoring on Urban Spatial Science in University College London. And I ' m planning to analysis the variability of Fire Responds Time as my theysis. I am writing to seek your professional clarification on a few specific issues I encountered within the London Fire Brigade Incident Records and London Fire Brigade Mobilisation Records datasets which were published in LONDON DATASTORE. 1. Systematic Loss of Second-Precision Since 2021 * Within the London Fire Brigade Mobilisation Records open database, I noticed a significant change in data precision. * In the files LFB Mobilisation data from 2021 - 2024 and LFB Mobilisation data 2025 onwards.xlsx, the chronological columns (DateAndTimeMobilised, DateAndTimeMobile, DateAndTimeArrived, DateAndTimeLeft, and DateAndTimeReturned) have lost their second-level precision. * The seconds component for all these timestamps is showing as 00 and automatically rounding up to the nearest minute. Compared to the 2009–2020 datasets, this represents a noticeable loss of granularity. * I suspect this truncation might be an unintended artifact introduced when internal files were compiled or converted into CSV format, as spreadsheet-to-CSV pipelines often drop second-level formats by default. * Could your team please provide the original high-precision .xlsx data for 2021–2024 and 2025 onwards? If this change was intentional due to updated privacy or information governance policies, is there an option for me to formally apply for the precision data under an NDA for academic purposes? 2. Interpretations of Historical vs. Contemporary Timestamps * My study relies on the public response time data from both London Fire Brigade Incident Records and London Fire Brigade Mobilisation Records. * I would like to confirm if the TimeOfCall column in the Incident Records and the DateAndTimeMobilised column in the Mobilisation Records represent different operational stages. * In records spanning 2009–2015, I observed a distinct time gap between TimeOfCall and DateAndTimeMobilised for the same IncidentNumber. I interpreted this gap as the interval between the control room receiving the call and dispatching the station. By combining this gap with TurnoutTimeSeconds and TravelTimeSeconds from the Mobilisation records, so I could calculate a comprehensive response time including call-handling duration. * However, starting from 2016, TimeOfCall and DateAndTimeMobilised become virtually identical, with only a 0 or 1-second difference in a small number of cases. * Did an operational system upgrade after 2016 enable instant dispatching to achieve this near-zero delay? Or was the exact timestamp gap masked for privacy reasons? If it is due to privacy, is it possible to apply to see the original exact gaps for post-2016 data? 3. Data Discrepancies and Mismatch Rows * While performing data linkage via IncidentNumber, I found a minor row mismatch between the two databases. * There are 777 instances in the Incident Records where pumping appliances were deployed, but their IncidentNumber cannot be found or matched in the Mobilisation records. * Conversely, there are 7,980 vehicle deployment logs in the Mobilisation records whose IncidentNumber cannot be matched to any master row in the Incident Records. * Although this discrepancy is very small relative to millions of historical records, I would appreciate it if you could briefly explain the operational or database logging reasons behind these unmatched entries. 4. Discrepancies Between Administrative and Physical First Arrival Times * When executing the dataset match, I cross-referenced the FirstPumpArriving_AttendanceTime column (Incident Records) with the minimum value of AttendanceTimeSeconds across all deployed pumps for the exact same IncidentNumber (Mobilisation records). * I discovered 8,820 instances where these two values do not match. * Does this discrepancy occur because FirstPumpArriving_AttendanceTime represents the time for the appliance that was designated/dispatched first, but due to real-time road conditions or different travel distances, a secondary or subsequent appliance actually arrived at the scene physically earliest? Thank you very much for your time, support, and continuous dedication to maintaining this vital public data resource. I look forward to your professional insights.
Response
Please see the response in the link below.
Documents
This is London Fire Brigade's response to a freedom of information (FOI) or environmental information regulations (EIR) request.
You can browse our other responses or make a new FOI request.