London has the data. Citizens rarely see the benefit

Transport for London spends roughly a million pounds a year publishing its open data. The assessed annual return is a range, between £90 million and £130 million. That ratio, from Deloitte’s July 2017 assessment for TfL, is the most cited number in British open data and one of the least examined, starting with the fact that the £130 million is the top of the range rather than the middle of it.

It deserves examination, because what is inside it explains why a Londoner can benefit enormously from the city’s data and never once encounter it.

Most of the benefit is time

The largest single component is saved travel time for network passengers, put at between £70 million and £90 million a year. Better journey planning is valued at up to a further £20 million through additional trips people take because the network became easier to use. Moving travellers off paid SMS alerts onto free apps is worth up to £2 million, with the use value of the new alerting services put at up to £3 million.

The commercial component is much smaller. Companies reusing TfL data commercially were assessed as generating between £12 million and £15 million in gross value added annually, supporting around 500 direct jobs and a further 230 in the supply chain.

Read that composition carefully. Saved passenger time dominates at both ends of the estimate, £70 million of a £90 million low case and £90 million of a £130 million high case, which is somewhere between seven tenths and four fifths of the total. It is not revenue, not jobs and not a service the city delivers. It is the monetised value of minutes that Londoners did not spend standing on a platform. The report counted 13,000 registered developers and, in TfL’s own foreword, over 600 apps powered by its data used by 42% of Londoners.

This is what the phrase “citizens rarely see the benefit” actually means. The benefit is genuine, it is large, and it is invisible by construction. Nobody experiences the absence of a wait. They experience an app that told them to leave in four minutes, and they attribute that to the app.

The value moved off the portal years ago

The London Datastore launched as the flagship of this agenda, and it is still running. So it is possible to ask a simple question about it: how much of it is alive?

On 13 August 2026 the Datastore held 1,298 datasets. Of those, 241 had been modified in the previous twelve months, or 18.6%. Six hundred and seventy-seven, 52.2% of the catalogue, had not been touched in over five years. Ninety-six had no data file attached at all.

The method matters, so here it is. Those figures come from the Datastore’s package_search API, reading the metadata_modified field on every dataset in one pass. Unlike some catalogues, this one is the origin rather than a harvester of other people’s records, and the field tracks real changes. The check for that is direct: the daily cycle hire dataset carried a package modification timestamp of 29 July 2026 at 08:15:53, and an HTTP request for the file itself returned a last-modified header of 29 July 2026 at 08:15:52. One second apart. The metadata is following the file.

The distribution of activity is the more revealing part. Of the 241 datasets updated in the past year, the Greater London Authority and its own teams account for around 40%. The portal is being kept alive mainly by the organisation that runs it.

Transport for London barely uses it

Twenty-eight datasets on the London Datastore are attributed to TfL. Five of them were updated in the past year.

That is not neglect. It is the whole point. TfL’s real open data output is not a catalogue of spreadsheets, it is a unified API publishing live arrivals, service status, disruption and timetables, which developers register for and consume continuously. The £130 million was produced by a feed, not by a download page.

Which sets up the honest conclusion about city data portals, and it is not the one their critics usually reach. The portal did not fail because London stopped caring about data. It failed to matter because the data that carries economic value is real-time and machine-consumed, and a catalogue of periodically refreshed files is the wrong shape for that. What remains on the portal is the residue: statistical series, one-off studies, historic extracts, and a long tail of entries that had a purpose in 2014.

There is a caveat worth stating rather than burying. A publisher who overwrites a file without any change to its record would not show up in these counts, and the Datastore’s own timestamps are the best available evidence rather than proof. The direction of that bias is knowable though. It would make the catalogue look staler than it is, and it would not move a figure like 52.2% untouched in five years by anything approaching enough to change the conclusion.

What a citizen would have to notice

Set aside the developers for a moment and ask what would have to be true for a Londoner to see a benefit from city data directly, without an app between them and it.

They would need a question they actually have. Whether this street floods. Whether this school has places. How long this hospital’s waits are. Whether the landlord letting this flat has been prosecuted. Almost none of those are answerable from a dataset. They are answerable from a service that consumed several datasets, resolved the addresses, and made a judgement about what counts as an answer.

Building that service is the expensive part, and it is the part a portal explicitly declines to do. The open data settlement was that the public body publishes and somebody else builds. For transport, where the audience is millions of people making the same query several times a day, somebody else did build, and the arrangement worked. For flood risk, school admissions or housing enforcement, the audience for any single query is small, the data is spread across several bodies with incompatible identifiers, and no commercial product emerges. So the data sits published and unused, which looks identical to the data being unavailable.

That asymmetry is the actual finding about smart cities, and it is not about sensors. A city can only outsource the last mile of its data to the market where the market has a reason to run it. Everywhere else, publishing is where the work stops rather than where it starts.

Two things London could do that cost almost nothing

Publish a truthful freshness signal. Every dataset on the Datastore already carries a modification date. Almost none carries a statement of how often it is supposed to be updated, which means a reader cannot distinguish a series that is deliberately annual from one that was abandoned. That difference is the single most useful piece of metadata a portal can hold and it is a form field.

And retire things on purpose. A catalogue in which half the entries have not moved in five years is not richer than one with 600 maintained datasets. It is harder to use, because every search returns a mixture of live and dead and the reader has to check each one. Deletion is unpopular in public bodies because it looks like reducing transparency. It is the opposite: an archive flag on a stale dataset tells a user something true that they currently have to work out for themselves.

The national version of this count, run against data.gov.uk with a different and messier method, is at counting the open data portals still being updated. How the whole apparatus came to be built, and the moment the momentum went out of it, is covered in open data began well, then it stopped. Further coverage sits under data and analytics.