The short answer
Build the portal around datasets people request rather than what is easy to export. Publish raw machine-readable open formats (CSV, JSON, GeoJSON) with field definitions, licences and refresh dates, expose recurring queries through a simple versioned API, and treat usability as a product to maintain, not a project to finish once.
Key takeaways
- Select datasets by measurable demand — public-records requests, service queries, media and analyst questions — rather than by how easy they are to export from an internal system.
- Publish raw machine-readable data in open formats (CSV or JSON for tables, GeoJSON or GeoPackage for geometry) and keep polished dashboards as a layer on top, never as a substitute.
- Treat metadata as part of the product: field definitions, licence, provenance, update frequency, a named steward and an honest quality note on every dataset.
- Design the API around recurring questions: a stable base URL, explicit versioning, filters and pagination, an openly declared coordinate reference system and documented rate limits.
- Design the dataset page like product UX: a prominent download action, a live preview and a column dictionary — because these are the controls users actually click.
- Run the portal as a lifecycle, not a launch: assign owners, publish refresh schedules, version changes, retire stale sets and capture usage analytics and feedback to keep improving.
Choose datasets by demand, not by export convenience
The most common reason a portal goes unused is that it is filled with tables nobody asked for. Publishers export whatever their internal systems can produce, upload hundreds of files and call the job done. Users open the portal looking for answers to concrete questions — where the recycling route runs, when a road was resurfaced, how call volume to a helpline has changed. A better selection method starts from demand: which questions do residents, journalists, analysts and app developers actually ask, and which recurring reports does the city still assemble by hand?
Mature catalogues publish explicit inclusion criteria: data should be specific to the place, available online, the best source for its type, structured and machine-readable, documented, supplied on an ongoing basis by a reliable owner, and supportive of public good or civic engagement. Run every candidate through these tests before release, not after.
Fewer can be better. Twenty curated, refreshed datasets with known owners build trust faster than two hundred stale spreadsheets. Each release should have a named steward who can explain the numbers and accept corrections.
- Demand signals: records requests, 311 and service inquiries, councillor and media questions, repeatedly requested internal reports.
- Prioritize data about accountability, service delivery and efficiency over purely internal statistics.
- If a dataset is never downloaded or requested for a year, improve its description or decommission it.
Publish raw data in open formats with metadata users can trust
The boundary between open data and a nice website matters. A polished dashboard or interactive map is a data product, but not necessarily open data: users can view it yet cannot download or rebuild it. The reliable pattern is to release the raw machine-readable data underneath and let dashboards sit on top. Open formats for tables are CSV and JSON; for geometry, GeoJSON or GeoPackage. They carry no proprietary restrictions and can be processed with free tools.
Metadata decides whether numbers can be trusted and reused. For each column publish a field definition; for each dataset state who produced it, when it was last refreshed, how often it updates, under which licence it is released and what known quality gaps exist. Machine-readable catalogue metadata (for example using DCAT) also helps search engines and central catalogues index the sets, so people can discover them from outside the portal.
Spatial data adds a specific trap: geometry depends on the coordinate reference system (CRS) in which it was recorded. Be explicit about the CRS used and careful when re-projecting, because accuracy can be lost. International guidance recommends declaring identifiers, licence and geometry openly and aligning spatial publication with the FAIR principles of findability, accessibility, interoperability and reusability.
Design the API around the questions people repeat
A portal that only offers files serves people who need a one-time download. An API serves ongoing consumers — a dashboard that must stay current, an alert service, a model that needs fresh data every night. The pragmatic order is: first provide complete bulk downloads, then expose the recurring queries as endpoints. Do not build a wide API nobody calls if the data is requested once a year.
A usable API is small and predictable: a stable base URL, explicit versioning so breaking changes never surprise consumers, filters for the common dimensions (time period, category, geography), pagination for long result sets and documented rate limits. For spatial sets, offer standard endpoints such as GeoJSON features or OGC API - Features rather than inventing a private scheme, so existing GIS tools can connect directly.
Document the contract and keep examples: a sample request and response per endpoint, expected field types, how nulls are handled and a changelog. Treat the API as part of the catalogue: register it beside the datasets and version it with stable identifiers so a linked application keeps working.
Make the dataset page usable, not just present
The point where reuse lives or dies is the individual dataset page — the landing page users reach from search. What users want most there is a direct download and definitions of the columns; portal support data shows downloads and column dictionaries are the most-clicked controls. Providing a field dictionary, a quality note and a live preview of the actual records removes the guesswork that stops non-specialists before they begin.
Cities that treat their portal as a product rather than a project run user research before redesigning: jurisdictional scans of other portals, surveys of their own users and usability tests with working prototypes. In one such programme a hybrid layout that combined tabs and accordions — keeping download prominent while letting users expand details per resource — beat pure tabs because it reduced visual clutter and scrolling. Even a small number of interviews pointed the redesign in the right direction.
Concrete usability rules follow: put one prominent download action per resource, show a live preview, place field definitions next to the data, name datasets briefly but specifically, and say in plain language what the data covers and what it does not.
Govern the lifecycle: licence, owners, refresh and retirement
Open data is only trustworthy when someone is accountable for it throughout its life. Assign a named steward per dataset, list an author or maintainer on the page and give users a way to report errors that actually reaches that owner. Decide the licence up front and state it on every page so commercial and non-commercial reuse is unambiguous.
Refresh is a commitment, not an afterthought. Publish an update frequency, automate the extract-transform-load pipeline where possible so timeliness matches the promise, and keep a change log. When a dataset is replaced or retired, version it or mark it superseded rather than deleting it silently, so applications built on top break predictably instead of mysteriously. Coordination between departmental data stewards and central IT is what keeps quality consistent across the catalogue.
Measure actual use and close the loop
Usage data tells you what matters. Track downloads, API calls, top searches and which datasets get cited in apps or the news, and combine that with qualitative signals: requests, bug reports and community feedback. If a set is never downloaded and never requested, either improve its discoverability and documentation or decommission it — an empty page with no users costs maintenance and adds noise.
Close the loop by showing what was made with the data. Highlight applications and analyses built on your releases, thank contributors and recruit a small group of beta testers from local meetups and universities. Reuse is the goal: when citizens and companies build on the data, the portal stops being a catalogue and becomes infrastructure.
Put it into practice
Dataset launch gate — a readiness checklist
Run this gate before any dataset or API endpoint goes live. Mark each item yes/no and release only when the critical items pass and the steward accepts a documented plan for the rest. It forces the decisions that separate a used portal from an unused one.
- The dataset answers a named request or use case, not just "we exported it".
- A named steward with contact details is listed on the dataset page.
- The file is machine-readable and in an open format (CSV, JSON, GeoJSON, GeoPackage).
- A field dictionary defining every column is published.
- The licence (e.g., CC BY or ODC) is stated without ambiguity.
- Provenance and update frequency are documented.
- A quality note with known gaps is present, not just promotion of the data.
- For spatial data, the coordinate reference system is declared and nothing is silently re-projected.
- For APIs: stable base URL, version and an identifier policy exist.
- Refresh is automated or has a visible schedule and change log.
- A feedback channel on the page routes to the steward.
- Analytics tagging is installed so downloads and API calls are measurable.
Questions people ask
Which datasets should we open first if we have limited resources?
Start with a handful of high-demand datasets that are ready and explainable, not with an exhaustive catalogue. Look for demand signals: repeated public-records requests, resident inquiries into service channels, questions from journalists and councillors, and reports your own staff assemble manually. Pick a dataset with a stable source and a named owner who can maintain it. Twenty refreshed, curated datasets with known stewards build trust faster than two hundred stale spreadsheets. The key is to fix the loop from the start: publish, refresh, collect feedback and measure use so the portal demonstrates value early.
Is a dashboard the same thing as open data?
No. A dashboard or interactive map is a product on top of data: users see ready-made charts but cannot download and rebuild the underlying records, so it usually does not count as open data. The reliable pattern is to publish the raw machine-readable data that powers the visualization and treat the dashboard as a separate layer above it. Link the two both ways — from the portal to the dashboard and from the dashboard to the raw data — so a user can view the summary and verify the calculation against the source records.
Do we need an API if we already publish CSV files?
Not necessarily. If data is requested occasionally, a full download as an open file format is sufficient and machine-readable. An API matters for ongoing consumers: a dashboard that must stay current, an alert service or a model that needs fresh data on a schedule. A pragmatic order is to provide complete bulk downloads first, then add endpoints for the queries that genuinely repeat. If you do publish an API, document it — stable base URL, versioning, filters and pagination, example requests, null handling and rate limits — and treat it as part of the catalogue rather than a separate project.
What formats should we choose for spatial (GIS) datasets?
For geometry, favour open standards without proprietary restrictions: GeoJSON works well for web applications and APIs, while GeoPackage suits desktop GIS workflows. Attribute tables travel well as CSV or JSON. The most important spatial rule is to state the coordinate reference system (for example WGS84) in which the geometry was recorded, and to be cautious when re-projecting, since accuracy can be lost. For API access use standard schemes such as GeoJSON features or OGC API - Features so existing tools connect directly instead of through a private protocol.
Who should be responsible for metadata and the refresh schedule of a dataset?
Assign a named data steward in the source department who understands the content and can answer questions and corrections, rather than leaving everything to central IT. The steward owns accuracy, quality and correct field descriptions; IT owns a reliable portal, automated extract-load pipelines and minimum metadata requirements. The partnership keeps the catalogue consistent: without a steward, sets go stale and errors go unanswered; without IT, publication stays manual and irregular.
How can we tell whether the portal is actually being used?
Combine quantitative and qualitative signals. From metrics, watch download counts, API calls per endpoint, popular search terms and which datasets get cited in applications, news or research. Qualitative signals include requests for new datasets, error reports and community feedback. If a set is neither downloaded nor requested, the problem may be discoverability and documentation rather than lack of interest — try improving the description before retiring it. Finally, surface and showcase what people build with the data, so reuse becomes visible and attracts more of it.
Sources and further reading
Sources were checked when this page was generated. Confirm changing dates, rules and prices with the original publisher.
- Spatial Data on the Web Best Practices (W3C/OGC Working Group Note)W3C / Open Geospatial Consortium
- The Open Data Handbook (English edition)Open Knowledge Foundation
- Руководство по открытым данным (русскоязычное издание)Open Knowledge Foundation
- The What and Why of Open Data — California Open Data Publisher's HandbookState of California
- CKAN User Guide — Datasets, resources and organizationsCKAN / Open Knowledge Foundation
- Updating our dataset page to better meet user needsCity of Toronto Open Data
- FAQ — OpenDataPhilly: criteria for including a data setOpenDataPhilly / City of Philadelphia