The short answer
Urban data quality cannot be reduced to one number: it rests on at least four measurable dimensions — completeness (are there gaps in coverage and attributes), freshness (does a record reflect current reality), lineage (where a record came from and how it changed) and ownership (who is accountable for a dataset and its updates). The workable approach is to score each dimension with its own metric and log the results in a quality register together with the named dataset owner.
Key takeaways
- Completeness has two faces: missing objects entirely in a layer and empty mandatory attributes on objects that do exist.
- Freshness is not the file's last-updated date but the gap between the pace of real-world change and the update frequency.
- Lineage documents source, creator, timestamps, coordinate transforms and every revision, so consumers can tell measured data from predicted or volunteered data.
- Every dataset needs one accountable owner plus a working data steward, or quality quietly becomes nobody's job.
- Quality is always relative to a task: standards deliberately avoid setting minimum levels and leave them to a dataset's product specification.
- Standard metadata schemas such as DCAT make municipal datasets far easier to attribute to a region automatically, improving reuse across departments and cities.
- With AI and digital twins, poor lineage and hidden gaps get amplified by algorithms, so quality discipline compounds in value over time.
Why a city can only govern what it can measure
City agencies steer what they can measure. Registers, GIS layers, sensors, citizen reports and contractor returns all turn into decisions — where to clear snow, which signal to retime, where to build a school. If those feeds carry silent gaps or stale records, the decisions look evidence-based but rest on a distorted picture. The usual problem is not too little data; it is not knowing how complete, current and traceable the data actually is.
International standards now converge on a shared frame. ISO/IEC 25005-1 treats data as a strategic citywide resource and organises its use around five dimensions: availability, quality assurance, ease of use, security and data-enabled innovation. For geodata specifically, ISO 19157-1 defines the components for describing quality and the procedures for evaluating it, yet deliberately avoids setting minimum acceptable levels — those belong in a dataset's product specification. The practical consequence is that 'good enough quality' only exists relative to a concrete use.
- Do not confuse data volume with data quality — volume never replaces measuring the dimensions.
- Agree on quality thresholds before analysis, not after defects surface.
- Record audit outcomes in a shared quality register rather than in the owner's memory.
Completeness: hunt for gaps, not just errors
Completeness is a question about holes. A dataset can be error-free in the records it holds yet cover only half the streets, buildings or buried utilities. In practice completeness splits in two: either whole objects are missing from a layer (new buildings, added alleys) or existing objects lack mandatory attributes such as an address, surface type or floor count. Different sources behave differently — volunteered geographic data, official cadastres and commercial vendors each cover some neighbourhoods densely and leave others nearly blank.
Completeness can and should be measured quantitatively. For point or building layers, compare the object count against an independent reference — imagery, an official register, or field checks on a sample of blocks. For attributes, compute the share of records with each required field filled. A useful signal is mapping saturation: if new edits add almost no objects, the layer is probably near complete; if every check finds dozens of omissions, the set is still young. That logic is widely applied to volunteered data such as OpenStreetMap, where uneven coverage between districts is expected rather than anomalous.
- Track 'object completeness' and 'attribute completeness' separately — they improve through different actions.
- Validate against an independent reference on at least 5–10% of the territory.
- Flag known gaps in the metadata instead of leaving them invisible to downstream consumers.
Freshness: current relative to the pace of change
Freshness is defined not by the date of the last update but by the gap between how fast the real world changes and how often the dataset is refreshed. A layer of traffic signs changes rarely, so a monthly lag is harmless; traffic flow changes in minutes, making yesterday's data useless for operations. The same dataset can be fresh for planning and hopelessly stale for operational control.
State the freshness requirement as the maximum tolerable delay between an event and its appearance in the data, rather than 'we update quarterly'. For sensors that means reporting latency and polling rate; for registers, the time from permit issuance to entry; for citizen reports, the time until a status is set. Keep a change history — when each record was created and last edited — so you can distinguish a genuinely stale layer from one that simply had nothing new to record.
- Stamp every record with created and edited timestamps — the foundation of both freshness and lineage.
- Set the refresh target from how fast the object changes, not from the calendar.
- Separate 'not updated for a long time' from 'updated but little changed' — they are different signals.
Lineage: the life story of every record
Lineage answers where a record came from and how it has been transformed. Metadata captures source, creator, timestamps, coordinate transformations, tools used and each revision. Without that trail, two identical-looking records can have very different reliability — one from a cadastre, another traced from a satellite image. W3C materials on data quality on the web tie provenance description directly to trust and propose vocabularies and metrics that let a publisher or a consumer judge a dataset's fitness for purpose.
Standards-based metadata pays off in practice. A study of municipal open-data portals found that portals using the DCAT metadata standard reached roughly 90% of datasets attributable to a specific region, against about 55% for portals with non-standard schemas. For geodata this means every record should carry a spatial reference (coordinates or a territory code) and a source identifier. When lineage is undocumented, consumers cannot tell measured from predicted, official from volunteered — and every downstream decision inherits that ambiguity.
- For each record record the source, creator, date, acquisition method and edit history.
- Use standard spatial-reference fields so datasets can be attributed to a territory automatically.
- Label source reliability status (official, volunteered, derived, predicted) per dataset or per record.
Ownership: every dataset needs a named accountable party
Without assigned accountability, quality quietly becomes nobody's job. City practice distinguishes the owner — the person who approves field definitions and is answerable for timely updates — from the steward, who day to day watches completeness, duplicates and consistency. Responsibility is fixed through an ownership matrix that lists, for every dataset, the business owner, technical owner, source system, update frequency, quality rules and retention period.
Ownership of urban data is broader than internal administration. Barcelona's 'New Data Deal' programme, studied in academic work, shows city governments actively trying to regain access to and control over data collected on their streets by technology platforms — pressing for rights in procurement and contracts rather than relying on goodwill. The Open Data Institute similarly argues that data infrastructure must be built so that systems stay transparent, accountable and trustworthy. Bring these expectations into vendor contracts: require a data dictionary, documented APIs, export formats, audit logs and a handover package at the end of the engagement.
- Assign one accountable owner and a separate working steward for every dataset.
- Put data, export and handover requirements into procurement documents and contracts.
- Run a monthly quality review attended by the named dataset owners.
Audit method: from data dictionary to register — and typical pitfalls
Start by describing the dataset in a data dictionary: field, definition, allowed values, whether required, owner and an example. Then measure each of the four dimensions with its own metric — share of filled fields, maximum update delay, presence of a lineage record and a named owner. Third, set target levels in the product specification and configure automated checks for completeness and format at ingestion, so bad rows fail early. Fourth, manage the cycle: recompute the metrics on schedule, review deviations with owners and refresh the quality register.
The biggest error is believing one quality score describes a dataset. A layer that is perfectly complete for address geocoding can be unacceptable for accessibility analysis because its roads are stale. A second common mistake is treating a file's date as proof of freshness or confusing 'no data' with 'data is zero'. A third is economising on metadata, which quietly makes datasets unusable by other departments and contractors. Finally, avoid the permanent pilot: start with one visible dataset or workflow, drive it to a stable quality level, then replicate the method.
- Write the data dictionary before the first load, not after the first errors.
- Automate completeness and format checks at the ingestion boundary.
- Recompute quality metrics on a schedule and keep the register with owners up to date.
- Represent missing values as a distinct state rather than merging them with zeroes.
- Validate quality against the task where the dataset is actually consumed.
- Start the audit with one dataset that underpins a visible resident-facing service.
Quality as an asset for AI, twins and procurement
Reliable data saves money and time by removing repeat site visits, duplicate work orders and version conflicts between departments. A dataset with documented lineage and an owner is easier to hand to a new contractor, to fuse into a digital twin, or to use for training models without fear that errors will spread across systems. Quality here is engineering discipline, not paperwork.
As AI and digital twins spread, the cost of poor data rises: algorithms amplify any systematic error in the source records. Money spent on completeness, freshness, lineage and ownership therefore pays twice — once for today's dashboards and again for the automated services that will learn from the same data tomorrow. Making data governance a condition of procurement protects the city against lock-in and invisible data loss.
- Treat data quality as a long-lived asset rather than a one-off cleanup.
- Factor data quality into digital-twin and analytics planning from the start.
- Demand a data dictionary and change log from suppliers as a condition of contract.
Put it into practice
Urban dataset quality audit checklist
Use this checklist to score any city dataset — a register, a GIS layer or a sensor feed — across the four dimensions in a single pass and to record who is accountable. Run it before publication, procurement or connecting the dataset to a dashboard.
- Object completeness: compare the object count with an independent reference on a territory sample and record the estimated coverage.
- Attribute completeness: compute the share of records with each required field filled and note which fields are critical.
- Freshness: state the maximum tolerable delay between an event and its appearance in data; record the update cadence.
- History: confirm that created and last-edited timestamps are stored for every record.
- Lineage: document the source, acquisition method (official, volunteered, predicted) and any coordinate transform applied.
- Metadata: verify the dataset carries a spatial reference and a data dictionary defining every field.
- Ownership: name the accountable business owner and the steward who handles updates and defect resolution.
- Automated checks: confirm completeness, format and allowed-value validations run at ingestion.
- Quality register: log the dataset with current metrics, review date and owner name in the shared register.
- Fit-for-use statement: record which tasks the current quality supports and which it does not.
- Contract readiness: verify that export, data dictionary and change-log requirements exist in documentation.
- Improvement plan: list two or three concrete actions and their owners before the next monthly review.
Questions people ask
How does dataset completeness differ from accuracy?
Completeness describes the absence of gaps: whether objects are missing from a layer and whether existing records lack mandatory attributes. Accuracy describes how well the values that do exist match reality — for example positional accuracy of coordinates or whether an attribute is correct. A dataset can be complete yet inaccurate (every building present, but some addresses wrong) or accurate yet incomplete (what exists is right, but half the objects are missing). Audits should therefore measure the two separately.
How frequently must city data be refreshed to count as current?
There is no universal figure: freshness is relative to how fast the object and the task change. A traffic-sign layer can be current with monthly updates, while traffic flow needs updates within minutes. Instead of a calendar cadence, define the maximum acceptable delay between a real-world event and its appearance in the data, for example 'no more than 24 hours from permit issuance to registry entry'. The dataset owner sets that target against the intended use.
What should a lineage field contain so another department can reuse it?
A workable minimum is: data source, creator or producing system, creation date and time, acquisition method (measured, manually entered, predicted, crowdsourced), any coordinate transformation applied, and a revision history. Add a spatial reference (territory code or coordinates) and a source-reliability label. That is enough for a downstream consumer to judge whether a given record can be trusted without contacting the original author.
Who should own a city dataset — the IT department or the domain team?
The domain or business unit that understands the meaning of the data and drives its updates is normally the accountable owner, while IT acts as technical owner responsible for storage and access. A data steward — someone who watches completeness, duplicates and consistency day to day — supports both. Fix this split in an ownership matrix that records, for every dataset, the business owner, technical owner, update frequency and quality rules.
Why do standard metadata schemas such as DCAT improve the quality of open city data?
Standard schemas impose the same required fields, including spatial reference and provenance, on every dataset. A study of municipal portals found DCAT-based portals achieved about 90% of datasets automatically attributable to a specific region, versus roughly 55% for portals using non-standard schemas. Automatic territorial attribution lets consumers find and filter data without manual parsing, which makes datasets reusable across departments and between cities.
How do poor-quality data become dangerous once AI and digital twins are involved?
Algorithms train and run on the source records and systematically amplify their errors. If a layer has coverage gaps or stale attributes, a model reproduces and enlarges those distortions — for example underestimating demand in neighbourhoods that are thinly represented in the data. Before wiring a dataset into a model, require documented lineage, measured completeness and freshness, and have subject experts review model outputs.
Sources and further reading
Sources were checked when this page was generated. Confirm changing dates, rules and prices with the original publisher.
- ISO/IEC 25005-1:2026 — Data use in smart cities — Part 1: FrameworkAFNOR / ISO-IEC
- ISO 19157-1:2023 — Geographic information — Data quality — Part 1: General requirementsAFNOR / ISO
- Data Quality Vocabulary (W3C Data on the Web Best Practices Working Draft)W3C
- Geographical Provenance of Open Government Datasets: Evaluating Geospatial Metadata in Municipal Open Data PortalsDublin Core Metadata Initiative
- Reclaiming data for improved city governance: Barcelona's New Data DealUCL Discovery / Urban Studies
- State of the Data Nation (Open Data Institute strategy review)Open Data Institute
- Smart City Data Governance and Data Quality for East AfricaGBOX Technologies