When I started building H-Park, a free, open-data PWA that maps accessible parking spaces across Europe, I expected the hard part to be the technology. Routing, geolocation, offline-first architecture, progressive web app constraints. The usual suspects.
I was wrong.
The technology was the easy part. The hard part was the data itself.
The promise of open data
Open data sounds revolutionary. Governments, municipalities, public institutions publishing datasets for free, under permissive licenses, accessible to anyone. The civic tech community has been celebrating this shift for over a decade, and rightly so: it represents a genuine philosophical leap from the idea that public information belongs to citizens, not to bureaucracies.
The EU's Open Data Directive, the countless national data portals, the smart city initiatives — they all point in the same direction. Transparency, accessibility, reuse. A virtuous cycle where developers and civic organizations build services on top of public information, creating value that governments alone could never produce.
In theory, this is one of the most compelling ideas of our time.
In practice, it is a battlefield of inconsistency, incompleteness, and quiet neglect.
What "open" actually means in 2026
The first time I looked for accessible parking data for a European city, I found it in seven different formats across three different portals, with four different coordinate systems, two of which were outdated. One dataset hadn't been updated since 2019. Another was technically open but required registration and approval from a municipal office. A third was open, recent, and well-formatted — but covered only one district of a city of 300,000 people.
This is not an edge case. This is the norm.
"Open" in civic data often means: it exists somewhere, in some format, under some license, updated at some unknown frequency, with some level of accuracy that nobody is officially accountable for.
That is a very different thing from open.
The four invisible barriers
1. Format fragmentation
Accessible parking data — to stay on the specific domain I know best — exists as GeoJSON, Shapefile, CSV with lat/long columns, XML, custom municipal APIs, and sometimes as a PDF table embedded in a city council resolution. Not joking.
Every format choice reflects a different tool, a different era, a different internal process. Nobody standardized anything because nobody talked to each other. The result is that a developer who wants to aggregate data from ten cities across three countries faces ten different ingestion pipelines before writing a single line of actual application logic.
OpenStreetMap remains, ironically, one of the most reliable sources for this type of data — not because institutions contribute to it systematically, but because individual volunteers do. The civic infrastructure that was supposed to solve this problem has, in many cases, been outperformed by a community wiki.
2. Temporal inconsistency
Data ages. A parking space that existed in 2021 may have been converted into a bike lane, a construction site, or simply removed. Open datasets rarely include a clear update cadence, and even when they do, the cadence is aspirational rather than enforced.
For a project like H-Park, stale data is not a minor inconvenience — it is actively harmful. A person with a disability who relies on our map to plan a route and arrives at a parking space that no longer exists is not slightly inconvenienced. Their day may be ruined. Their trust in assistive technology, already fragile, takes another hit.
This is the specific human cost of data neglect that is invisible when you look at a dataset from a policy perspective.
3. License ambiguity
I have encountered datasets labeled "open" that, upon reading the actual license document, required attribution in a specific format, prohibited commercial use, prohibited derivative works, or — in one memorable case — required that any application built on the data be submitted for review to the originating institution before publication.
The default assumption of the developer community is that "open data" means something close to CC0 or ODbL. It often doesn't. And the license text is frequently buried, poorly written, or inconsistent with what the portal homepage claims.
This creates real legal risk for anyone building something serious. And it creates a quiet chilling effect: civic developers start ignoring official datasets and defaulting to community-maintained sources precisely because community sources tend to have clearer, more permissive licensing.
The institutions end up being circumvented by the very developers they were trying to empower.
4. The accountability vacuum
When a commercial API returns wrong data, you have a support channel. You have SLAs. You have someone to contact. When official open data is wrong, you have a contact form on a municipal website that may or may not be monitored, and a response time measured in weeks or months — if you get a response at all.
There is no accountability structure for data quality in most open data initiatives. The data is published, the obligation is considered fulfilled, and what happens downstream is not tracked. Whether the data is used, whether it's accurate, whether it causes harm — none of this feeds back into the process.
This is not a criticism of the individuals who publish the data. Many of them are working hard with limited resources. It is a structural problem: open data publication has been treated as an output metric rather than a service metric.
The civic tech developer's silent choice
Every developer working in civic tech eventually faces a version of the same decision: do I build on official data and inherit its problems, or do I route around it and use community sources?
Most of us route around it. We use OpenStreetMap. We crowdsource our own corrections. We build lightweight contribution systems so that users can flag outdated information. We become, in practice, a parallel data infrastructure operating alongside the official one — sometimes more accurate, always more responsive.
This is an extraordinary waste of effort. Not because community data is bad — it's often excellent — but because the official systems should be doing this work, and they aren't. Every hour I spend building a crowdsource correction flow for H-Park is an hour I'm not spending on the actual user experience. Every workaround is a tax on the developer's time that ultimately reduces what the end user gets.
What good actually looks like
I don't want to be only critical. Some things work well, and they're worth naming.
Overpass API on top of OpenStreetMap is genuinely excellent: flexible, fast, and reflecting a data model that was designed for reuse from the beginning. The Linked Open Data community has produced some genuinely usable infrastructure, even if adoption is still limited. Denmark and the Netherlands have invested seriously in standardized geospatial data with real update cadences and developer-friendly APIs. They are proof that it's possible.
The difference is always the same: organizations that treat data publication as a product — with users, feedback loops, and quality standards — produce usable data. Organizations that treat it as compliance theater produce datasets that look good in a press release and break in production.
The regulation trap
The EU's Data Governance Act and the broader open data regulatory framework are well-intentioned, but they risk falling into the same trap: mandating publication without mandating quality.
You can require every municipality to publish their accessible parking data. If you don't require a minimum schema, a maximum staleness threshold, a validation process, and a response mechanism for errors, you will get technically compliant but practically useless datasets across thousands of institutions. Compliance without usefulness is bureaucracy, not progress.
The next step in open data policy needs to shift from what must be published to how it must behave. Data as a service, not data as a document.
H-Park exists because accessible parking data should be easy to find and reliable. It isn't. So we built something.
But I'm aware that what we built is, in part, a monument to institutional failure. Every crowdsourced correction, every manual data import, every format conversion script in our pipeline represents a gap that official systems should have filled.
The civic tech community is extraordinarily resourceful. We build around problems with elegance and creativity. But resourcefulness is not a substitute for infrastructure. And infrastructure is not something volunteers should be building in their spare time while governments publish PDF tables and call it open data.
Open data was supposed to democratize civic participation. Instead, it has too often created a two-tier system: institutions that publish, and developers who compensate for what the institutions got wrong.
We deserve better data. And the people who depend on what we build deserve better than workarounds.