Geospatial open data portal on CKAN

Why a geospatial data portal on CKAN needs a different build

A mapping agency, environment department or city that holds spatial datasets on GIS servers and in file shares can run CKAN as a self-hosted catalog, provided spatial metadata, map previews and links to existing GIS servers are treated as first-class requirements from the start. A generic open data portal treats a shapefile or GeoPackage as one more download. A geospatial portal has to describe the data's extent, coordinate reference system, scale and lineage, show users what the data looks like on a map, and point to the live service instead of copying it. CKAN's core model is flexible enough for this, but the extensions, metadata profile and hosting choices that deliver it are not default settings, so they need to be decided before the build starts.

The decision this page helps with is whether your spatial estate can be published through CKAN with harvested ISO 19139 records, a CSW endpoint from pycsw, and map-based search, or whether a different catalog or a GIS-native product fits better. Start by inventorying which datasets are authoritative in a GIS server, which are static files and which change often enough that a harvest or a link is preferable to a manual upload. Confirm with your GIS team which map services, such as ArcGIS REST or WMS endpoints, must be referenced from CKAN, and whether any of them sit behind access controls that the portal must respect. Confirm also which metadata profile your national or sector guidance requires, because that determines the fields your harvester must map and validate.

Which requirements shape the geospatial build and where they come from

This table maps each spatial-data requirement to its source and to the build decision it forces. Read it as a checklist: where the source is a law or deadline, plan against it; where the source is the agency's own catalog obligations, confirm the scope with the owners before design starts. The main takeaway is that metadata harvesting and GIS server links depend on what your existing systems already publish.

Requirement	Source	What it means for the build
ISO 19139 metadata harvesting	Agency catalog obligations and any national or sector metadata profile the agency must follow	Confirm which ISO 19139 records exist, who maintains them and whether they are current. Plan the harvester, field mapping and a validation step before publishing.
CSW discovery through pycsw	Agency catalog obligations and discovery expectations from spatial data users or national spatial data infrastructure	Decide whether external catalogs must query the portal. If yes, budget for CSW endpoint configuration, testing against client tools and ongoing record quality checks.
Map-based dataset search	Agency user needs and public accessibility duties	Define search by area, theme and format. Map controls must be keyboard operable and readable to assistive technology, which adds design and test effort.
Previews of GeoJSON and map services	Agency publishing workflow and public accessibility duties	Confirm which formats and service types must preview inline. Large or complex layers may need simplification or a link to the source server instead of a direct render.
Links to existing GIS servers	Agency GIS server inventory and security policy	Confirm whether the GIS servers already publish metadata that can be harvested. Check authentication, network paths and whether the portal should link or proxy.
Accessibility for state and local government	ADA Title II rule: WCAG 2.1 Level AA for web content and mobile apps; compliance dates April 26, 2027 (entities serving 50,000 or more people) and April 26, 2028 (smaller entities and special districts)	Establish which date applies to your entity and include map interfaces and downloadable previews in the WCAG 2.1 AA test scope. Vendor-supplied components must meet the same standard.
Ownership of spatial datasets across departments	Agency data governance and publication roles	Map which department owns each layer and who approves publication. Without this, metadata quality and update frequency drift after launch.

How ISO 19139 metadata, harvesting and CSW fit together

The metadata flow has four stages, and each one needs an owner. Spatial records are authored in GIS tools or a source catalog, typically as ISO 19139 XML documents describing datasets, services and their extents. A harvester then pulls those records into CKAN as datasets, where the spatial extent and the descriptive fields become searchable. The map-based search that users see depends on that indexing step, so a record that is harvested without a usable bounding box will be findable by keyword but not by place. Finally, a CSW endpoint built with pycsw republishes the catalog so that other catalogs, federated portals and INSPIRE-style discovery tools can query it. Each stage can fail silently, which is why the reader should assign a named owner to the source catalog, the harvest job and the CSW publication separately.

Before assuming a spatial harvester exists, confirm what your CKAN version actually supports. The ckanext-dcat extension covers DCAT RDF endpoints, DCAT-AP schemas and an RDF harvester, and it is supported on CKAN 2.10 and 2.11. It does not, on the facts supplied here, establish that ISO 19139 harvesting is handled by the same extension. Ask the implementation partner to name the spatial extension, the harvester type and the metadata profile they propose, then check each one against the CKAN release you plan to run, since CKAN 2.12.0 was released on August 26, 2026. Test the chain end to end with a small set of records from your real source catalog, including records with missing extents, mixed coordinate reference systems and out-of-date service links, before committing to the full harvest.

The CSW endpoint is a separate deliverable, and it should be scoped as one. pycsw publishes records to external clients, which means the team must decide which fields are exposed, how often the repository refreshes and who can change the published set. Write these decisions into the fixed scope before work starts, along with the validation you will run on exported records. Illustrative example: a city that harvests 2,000 records from a GIS server but publishes only the 1,400 marked as public through CSW needs a clear rule for the other 600, and that rule belongs in the requirements, not in the build.

Which CKAN deployment fits a mapping agency, environment department or city

A mapping agency or environment department that already runs a GIS server and has a small team usually needs one CKAN instance that publishes a focused set of spatial datasets and links to services the agency already operates. The main decision is how much of the operating load the team can carry. Under CKAN's release policy, the latest patch of the current minor version and the previous minor version receive security and bug fixes. With CKAN 2.12.0 released on August 26, 2026, alongside maintenance releases 2.11.6 and 2.10.11 on the same day, a team on 2.11 is still supported, but it must move to a newer patch as soon as one is published.

Patch cadence: Outdated patch releases lose support once a newer patch is out, so the team needs a routine for applying patches within the same minor version.
Minor upgrades: Minor releases may include backwards-incompatible changes, so each move from 2.11 to 2.12 needs its own test cycle against the agency's extensions and map previews.
Single instance: A single node keeps the Solr, Redis and PostgreSQL footprint small, but it also means one maintenance window for the whole portal.
Vendor support: Ask the implementation partner who applies patches when the small team is unavailable, and in what time frame.

Before committing, confirm with the agency's GIS team which map services and file formats must be previewed, because that list determines which extensions must be tested with each minor release.

Integration points that need an owner before go-live

A geospatial CKAN portal sits between GIS servers, metadata files and national catalogs, so each connection needs a named owner before launch. The cards below cover the points where data formats, identity and hosting decisions most often stall a project.

Existing GIS map services

Most agencies already run ArcGIS Server, GeoServer or MapServer. The portal should link to those services and preview them, not copy the data, so each service needs a stable URL, a documented layer list and a decision on who may read it. Confirm with the GIS team which services are public, which need credentials, and which layers carry restricted attributes that must be excluded from the portal.

ISO 19139 metadata sources

Spatial records often live in a GIS catalog or a folder of XML files that follow ISO 19139. The integration must decide whether records are harvested into CKAN or entered by hand, and who fixes records that fail validation. Ask the GIS team how many records are complete, which fields are mandatory for publication, and who signs off on changes to a record after it is published.

CSW endpoint built with pycsw

pycsw exposes the catalog through the Catalogue Service for the Web interface that many spatial tools expect, so harvesters and desktop clients can find records without using the portal interface. The endpoint must be configured against the same metadata store as the portal, and its public address needs a named owner. Confirm which CSW profile the national or regional consumers require and who tests queries after each upgrade.

SSO for staff publishers

Where the agency runs SAML for staff identity, ckanext-saml2auth connects CKAN logins to that identity provider so publishers do not manage separate passwords. The identity team must confirm the SAML metadata, attribute mapping for organization roles and how leavers lose access. Test that a user removed from the directory cannot still edit or publish datasets in CKAN.

DCAT RDF output for national catalogs

National and European catalogs harvest DCAT RDF, which ckanext-dcat can generate and read. Spatial datasets need their metadata mapped to the target profile, and gaps in the source records will appear in the national feed. Agree with the receiving catalog which profile version it accepts, which fields are mandatory, and how the agency validates output before each harvest.

DataStore for attribute tables

Tabular attribute tables tied to map features can be loaded into the CKAN DataStore, which provides a Data API with filtering and SQL queries. Loading uses XLoader, and the DataStore needs its own PostgreSQL database with a separate read-only user. Confirm with the GIS team which tables are safe to publish, how often they refresh, and whether geometry columns should be excluded before loading.

How a geospatial portal moves from inventory to live catalog

The sequence starts with knowing which spatial datasets exist and how well they are described, then builds a self-hosted CKAN catalog that harvests and serves that metadata. Each phase ends with a named output the agency or city can review before the next phase starts.

Inventory spatial datasets and metadata quality
Your team lists the spatial datasets to publish, the systems that hold them (file shares, GIS servers, spatial databases, existing catalogs) and the state of their metadata, including whether records follow ISO 19139 and carry required fields such as title, extent, reference system and contact. DeployOpen reviews a sample of records with your data owners and flags gaps, duplicates and records that point to services no longer running. The output is a dataset inventory with a metadata quality rating per dataset and a list of owners who must act before publication.
Decide hosting and data classification
Each dataset is classified as open, restricted or internal, and the hosting location is chosen to match. Your security and legal teams confirm which data may sit in which cloud account, data center or air-gapped network, and whether any framework such as the FedRAMP, CJIS or NIS2 rules applies to the portal or its hosting provider. Confirm the classification with the owners of your existing datasets, since it drives access control and what the harvester may expose. The output is a signed hosting and classification decision that fixes the target environment and the access model.
Install CKAN on the agreed stack
DeployOpen installs CKAN from source in your environment on the agreed stack: Python 3.10 or newer, PostgreSQL 12 or newer, Solr 9 (recommended) or Solr 8 for search, and Redis, with uWSGI and Nginx for production. Solr and Redis may run from Docker images tagged to your CKAN version if your standards allow containers. The DataStore is configured with separate write and read-only database users, and the map preview and spatial search extensions are enabled and tested. The output is a working staging instance, a documented build and a version pin that your team can reproduce.
Configure harvesters and CSW endpoints
Harvesters are configured to pull ISO 19139 records from your existing metadata sources, and pycsw is set up to expose a CSW endpoint so external GIS clients and catalogs can query the same records. DeployOpen loads a set of test records covering each dataset type, including a GeoJSON file, a map service link and a record with a missing field, and checks how each one appears in search, in the map view and in the CSW responses. Any mapping errors are corrected at the source or in the harvester configuration. The output is a test log showing each test record passing or failing, with the fixes applied and retested.
Test accessibility against WCAG 2.1 AA
The portal's public pages, search, dataset pages, map view and download flows are tested against WCAG 2.1 Level AA, including keyboard navigation, text alternatives for map content, color contrast and form labels. Where your organization is a state or local government body, the ADA Title II rule applies, so confirm your compliance date with your counsel before setting the test scope. Findings are logged by page and severity, fixed in the theme or templates, and retested. The output is an accessibility test report with the remaining issues listed and owners assigned, which your accessibility office can review.
Publish to production and hand over support
After staging sign-off, the portal is promoted to production with the monitoring, backup and restore procedures agreed in the scope, and the publishing workflow for your data owners is walked through with recorded sessions and written guides. Your operations team receives runbooks for upgrades, harvester failures, index rebuilds and CSW troubleshooting, and the ownership split between your staff and any retainer agreed in writing. The output is a live catalog, a handover pack and a named list of people who can approve changes and respond to incidents.

Evidence that accessibility and security reviewers will ask for

This table maps each piece of evidence to the component that produces it, so reviewers can ask the right owner for the right record. Read it as a checklist for the implementation handover: if a row has no owner or no retained record, the portal is not yet ready for review. DeployOpen prepares this evidence, but independent auditors and assessors decide whether it meets their requirements.

Evidence	Produced by	What the reviewer checks
WCAG 2.1 AA test report	Map viewer, dataset search and dataset pages, tested with assistive technology	Keyboard operation of map controls, text alternatives for map layers, and contrast on preview panels, against WCAG 2.1 Level AA
CSW and harvest logs	pycsw endpoint and CKAN harvesters importing ISO 19139 records	Record counts per harvest run, rejected records with reasons, and the source catalogue each record came from
Configuration baseline	CKAN configuration file, Nginx and uWSGI settings, Solr and Redis deployment	Versioned settings, change history and sign-off for each change, with secrets kept out of the repository
Patch-level record	Running CKAN version, OS packages and Python dependencies	The CKAN version in use against the current release policy, which supports the latest patch of the current minor and the previous minor
Access-control record	CKAN roles, organization memberships and any SAML2 single sign-on link	Who can view or edit restricted spatial datasets, how access was granted, and reviews of that access over time
Restricted layer handling	Dataset metadata flags and the links to GIS servers behind authentication	That restricted layers are not exposed through public previews, CSW records or cached tiles
Control mapping (federal reference)	Implementation team with the agency's assessor	Where a federal baseline could apply, the NIST SP 800-53B low (149), moderate (287) or high (370) controls and enhancements, mapped to the evidence above
Assessment decision	Agency assessor, auditor or certification body	DeployOpen prepares the evidence but does not issue audit reports, attestations or certifications

When FedRAMP, CJIS or CUI rules change where the portal can run

Before choosing a host, confirm which federal or criminal justice rule, if any, reaches the spatial datasets the portal will publish. FedRAMP scope covers cloud products and services that create, collect, process, store or maintain federal information on behalf of an agency. A CKAN portal run only for one agency's own operations on cloud infrastructure, and not offered as a shared service, may fall outside that scope, but a hosted or multi-tenant service used by several agencies generally will not. Ask counsel to document the scope decision in writing, including who operates the infrastructure and whether any other agency or contractor can use the portal. The FedRAMP scope guidance is the natural starting point for that conversation.

If any layer touches criminal justice information, the FBI CJIS Security Policy sets the bar. Version 6.1 requires FIPS 140-3 certified cryptographic modules, or FIPS 197 AES with at least 256-bit keys, for CJI in transit and at rest outside physically secure locations, up from 128-bit keys. For the portal, that means checking TLS termination at Nginx, the PostgreSQL and Solr storage volumes, Redis, and any backup targets for certified modules and key length. Vulnerability scanning must run at least monthly. Confirm with your CJIS Systems Agency and the policy's Requirements Companion Document, not with the portal vendor alone, since the control mapping depends on your agency.

Controlled unclassified information (CUI) raises a different question. Under 32 CFR 2002.14(h)(2), federal agencies must apply NIST SP 800-171 when setting requirements for CUI on non-federal systems, unless the CUI category's own authority prescribes other safeguards. Security-sensitive spatial layers, such as utility networks, water intakes, critical facility locations or protected habitat data, can be CUI even when the base map is open. Ask counsel to classify each layer before publication, and keep restricted layers on a separate CKAN instance or behind access controls, with the GIS servers they link to placed inside the same boundary. Note that CKAN's own release cycle does not change these obligations, so the assessment must cover the exact versions you run.

Questions buyers ask before hiring help for a geospatial CKAN portal

What drives the cost and effort of a geospatial CKAN portal?

The biggest drivers are how many spatial datasets you publish, how messy their metadata is, and which previews and GIS links you need. Costs fall into three groups: the one-time build (installation, the spatial extension setup, harvesting, and testing), the one-time data work (cleaning ISO 19139 records and mapping them to the catalog), and recurring work (hosting, patching, upgrades and support). Each group is paid to a different party, so ask any implementation partner for a fixed-scope quote that lists these lines separately. DeployOpen does not publish prices. Ask whether the quote covers CSW testing, the GIS server connections and handover documentation, since these are the items most often left out of a first estimate.

How long does a spatial portal take, and what depends on the metadata inventory?

Timing depends mostly on the state of the metadata inventory, not on the software install. A catalog with complete, valid ISO 19139 records can be harvested and tested far sooner than one where records are incomplete, duplicated or tied to retired services. Before agreeing a timeline, ask the partner to audit a sample of records, count the datasets that need manual correction, and confirm which GIS servers must be reachable during testing. No duration is quoted here because it depends on your records and environment, so ask for the schedule to be written into the fixed scope with the dependencies named.

What must the agency's GIS team provide before the build starts?

The GIS team should provide an inventory of spatial datasets and services, access to the metadata source, and named owners for each dataset who can approve publishing and licensing. They also need to confirm the coordinate reference systems in use, the endpoints of any existing map or feature services, and the security rules for connecting them to the portal. Ask the partner to list these inputs in the statement of work, with a date by which each must arrive. Delays in these inputs usually move the whole project, so treat them as project risks with owners rather than background tasks.

Can our in-house staff run the portal after launch?

They can, if the team has Python, PostgreSQL, Solr and Redis skills, and if someone owns the operating model. CKAN installs from source need Python 3.10 or newer, PostgreSQL 12 or newer, Solr 9 (recommended) or Solr 8, and Redis, with uWSGI and Nginx recommended for production. Staff must also handle harvesting jobs, index rebuilds, backups and user administration. Ask a partner for a written handover, runbooks for each component, and a support option for patches and incidents. Confirm internally who holds the on-call duty and who approves upgrades before deciding between in-house operation and a retainer.

How does the CKAN release policy affect maintenance?

The CKAN project targets about two minor releases a year, and the tech team supports the latest patch of the current minor version and the previous minor version. Outdated patch releases lose support once a newer patch is out, so a portal left on an old patch falls out of security coverage. CKAN 2.12.0 was released on August 26, 2026, alongside maintenance releases 2.11.6 and 2.10.11. Patch releases avoid breaking changes, but minor releases may include backwards-incompatible changes, so spatial extensions must be retested before each minor upgrade. Ask any partner to budget for this cycle and to state who carries it after go-live.

Can we test the CSW endpoint before the portal goes public?

Yes, the CSW endpoint should be tested on a staging instance before public release, using the same harvested records and a sample of clients. The test should confirm that pycsw returns valid ISO 19139 records for GetRecords and GetRecordById requests, that spatial filters return the expected datasets, and that records link correctly to their GIS services. Ask the partner which CSW operations are in scope, which client tools will be used for checks, and what evidence they will hand over. Confirm with your own data owners that the records shown in staging are ones they approve for public access.

How DeployOpen scopes and supports a geospatial CKAN portal

DeployOpen plans, implements, customizes, integrates, hardens, documents and supports self-hosted open-source platforms inside your own infrastructure. For a geospatial CKAN portal, that means agreeing the spatial data, metadata and GIS integrations in writing before work starts, then building and testing them in your cloud account, data center or air-gapped network.

How we scope

Inventory the spatial datasets, formats and map services that the portal must publish or link to
Confirm which ISO 19139 metadata records are harvested, which fields are mapped and who owns each source
Agree in writing the hosting location, identity integration, accessibility target and deliverables before work begins

How we build

Install and customize CKAN with its spatial extensions, PostgreSQL, Solr and Redis in your environment
Configure pycsw CSW endpoints, map-based search and previews for GeoJSON and map services
Test harvesting, search relevance, map rendering and access controls against the agreed scope

How we hand over

Document the architecture, configuration, harvest schedules and the operating runbook for your team
Provide the test results and compliance evidence that the agreed scope calls for, for your auditors to review
Walk your staff through publishing workflows, roles and the steps for adding new spatial sources

How we support

Offer ongoing support, upgrades and continuous testing as a retainer after go-live
Plan CKAN patch and minor upgrades against the project's published release policy
Confirm response expectations, service levels and upgrade windows in the retainer terms before signing