TL;DR — Open geospatial data is now an expectation, not a favor. Public agencies that publish parcels, roads, utilities, and environmental layers in 2026 are also expected to know — on demand — who consumed which dataset, when, and at what rate. This playbook describes the architecture that lets agencies meet both expectations: a single authoritative source on the inside, a governed gateway on the perimeter, and a queryable audit trail behind every outbound byte.
The open data movement assumed that publishing a dataset and walking away was the end of the operator’s job. That assumption stopped being true once open data started being load-bearing. When a citizen-facing app, a contractor’s field tool, a partner agency’s dashboard, and a researcher’s notebook all consume the same parcel layer, the dataset has crossed from “publication” to “production.” And production data needs the same accountability surface that every other production system in the agency already has.
The good news: the architecture that gets an agency there is well understood. The pieces are the same pieces that the rest of a modern ArcGIS Enterprise deployment uses — just composed in a way that makes outbound openness an operational property, not an accident.
The Open Data Dilemma in One Picture
Imagine a typical municipal scenario. The agency publishes ten public-facing layers on a download portal: parcel boundaries, zoning, addresses, road centerlines, public-transit stops, water and sewer mains (redacted), street trees, parks, building footprints, environmental coverage. Each layer is a dataset that downstream consumers actually depend on.
Now ask the questions that any internal information-security review will eventually ask:
- How many distinct external systems are reading the parcel layer this month, and which of them are the top three by request volume?
- If a single consumer began pulling the building-footprint layer at ten times its historical rate, would the agency notice in real time, or in the next quarterly report, or never?
- If a regulator asks for a record of every download of a redacted utility layer in the past twelve months, can the agency produce that record in one query?
- If a partner contract ends, does the agency have a mechanism to revoke that partner’s access without breaking access for the other consumers of the same layer?
For most public agencies in 2026, the honest answer to each of those questions is some shade of “not really.” That is the gap. Open data without operational risk is the architecture that closes it.
The Four Properties of Governed Open Data
Governed open data is not less open. It is not slower. It is not harder to consume. It is open data with four extra properties that the publishing agency — not the consumer — benefits from.
1. Authoritative Source on the Inside
There is exactly one official copy of every open dataset, sitting inside the agency’s ArcGIS Enterprise environment, owned by the department that produces it. The open feed is a derivative of that authoritative source — not a parallel, unsanctioned copy. This is the same single-source-of-truth principle that the Municipal GIS Playbook describes for internal consumption. Open data inherits it; it does not replace it.
2. A Governed Perimeter on the Outside
Outbound consumption flows through a single perimeter layer that does four things on every request: identifies the consumer, validates the request against an allowlist, applies a rate limit, and writes a structured audit record. This is the same governance pattern Rodosto detailed in Proxy Token Manager — Secure ArcGIS Enterprise Services. The mechanism is identical for partner-only services and for fully open public services. The only difference is the policy attached to the consumer record.
3. A Queryable Audit Trail
Every request is recorded as a row in a database the operator can query. Timestamp, consumer identity, request path, source IP, status code, response time. Retention is configurable per organization, from a short window for low-sensitivity layers to multi-year retention for layers that touch regulatory or legal review. The audit trail is the evidence that turns “we publish openly” into “we publish openly and we can prove it.”
4. Lifecycle Without Manual Effort
Tokens expire on schedule. Rate limits adjust through configuration, not code. Decommissioned consumers stop receiving traffic the moment the operator marks them inactive. Configuration changes propagate to the gateway automatically — the operator does not edit NGINX files by hand at midnight. The system runs itself between deliberate operator interventions.
The Reference Architecture
Inside: The Authoritative Source
Open datasets live inside ArcGIS Enterprise as feature services, image services, or vector tile services, federated with Portal for ArcGIS and backed by an enterprise geodatabase on PostgreSQL or Microsoft SQL Server. The dataset is owned by the producing department, sharing is controlled through Portal groups, and the derivative open feed is registered as a service whose source is unambiguous. Nothing about the open distribution requires bypassing or duplicating the internal model.
The Perimeter: Gateway, Tokens, Allowlists
Between the internal services and the outside world sits a gateway layer. For partner-only or contractor-only feeds, the gateway issues per-consumer tokens with referrer and IP allowlists, exactly as described in the Proxy Token Manager reference. For fully open public feeds, the gateway issues per-application tokens (one per consuming application, anonymous to the human user) and applies a rate limit calibrated against the upstream service’s capacity.
The point is not to gate access. The point is that every request, even an anonymous one, is attributable to some consumer record — an application, a tenant, a partner — so that anomalies are detectable and policy is enforceable.
Audit and Telemetry
Every request through the gateway is written twice: once as a structured row in an audit table (PostgreSQL is the conventional choice; the Proxy Token Manager reference architecture uses it), and once as a structured JSON line on the application log stream for ingestion into Loki, Elasticsearch, CloudWatch, Datadog, or whatever centralized observability the agency already runs. The two destinations serve two audiences: the audit table answers compliance questions, and the log stream feeds the operational dashboards.
Rate Limiting and Capacity Protection
Per-consumer rate limits prevent any single integration — intentional or accidental — from consuming a disproportionate share of the upstream ArcGIS Server capacity. A common failure mode for unrate-limited open feeds is an enthusiastic developer’s notebook that hits the parcel service in a tight loop and degrades performance for every other consumer. Rate limits at the perimeter make that failure mode impossible without operator awareness, because the rate-limited consumer’s requests appear in the audit log with a 429 status code that the dashboard surfaces immediately.
Lifecycle Automation
Token expiry, allowlist changes, retention pruning, and gateway configuration regeneration all run on schedule. The operator’s job is policy, not plumbing. New consumer onboarding produces an artifact — a per-consumer onboarding PDF with an API key, the assigned service paths, the rate limit, and copy-paste integration code for the ArcGIS JavaScript SDK, Leaflet, and OpenLayers — that compresses what was once a week of email into a calendar invite.
How Open Data Composes With the Rest of the Platform
The architecture above does not exist in isolation. It is the outbound face of the same ArcGIS Enterprise core that the agency runs internally. Three places it composes cleanly with the rest of the stack:
- Identity. Internal consumers authenticate against the agency’s identity provider (Azure Entra ID, Okta, ADFS) through Portal for ArcGIS. External consumers authenticate against the gateway’s consumer registry. The two registries do not have to merge — they have to be reconcilable, so an internal team can confirm that a given external partner is the same legal entity that signed the data-sharing agreement.
- Service tier. The same service that an internal department reads through Portal is the service that the gateway proxies to external consumers. There is no separate “open data” service that can drift from the authoritative version.
- Operations. The audit table and the log stream feed the same observability platform that the rest of the agency’s IT runs against. Open data outages are detected, triaged, and resolved on the same on-call rotation as any other production system.
For a deeper view of where these pieces sit inside the full ArcGIS Enterprise topology — data tier, service tier, portal and identity, governance perimeter, integration tier — see the Municipal GIS Playbook. This post is the outbound chapter of that playbook.
Common Failure Modes
Open data programs that do not adopt the architecture above tend to fail in predictable ways. A short list, in order of frequency:
- Static download URLs that nobody owns. A zipped shapefile published on a forgotten subdomain three years ago that thirty downstream systems still depend on, with no mechanism to deprecate, version, or audit. Every public agency has at least one of these. The right response is to bind that URL to the gateway and put a known consumer record behind every download.
- An “open” service with no consumer registry. If the gateway records a request as “anonymous” with no application-level identity, the audit trail is fictional. The right response is to require even open consumers to register an application token, however lightweight that registration is.
- Audit logs only in the proxy’s access log. NGINX access logs were not designed for compliance evidence. The audit trail belongs in a queryable database with a defined schema and retention policy — not in a flat file that gets rotated and lost.
- No rate limit on the parcel service. Parcel layers are the single most-abused open dataset in municipal GIS, because they are useful and because they are large. An open parcel service without a rate limit will, eventually, be hammered by an automated client and will degrade for every other consumer. Rate limits are not optional.
- Manual NGINX edits. If the operator opens a config file by hand to add a consumer, the configuration drifts and the disaster-recovery plan becomes fictional. Configuration regeneration belongs in code, not in muscle memory.
Implementation Cadence
The path from “we publish openly with no governance” to “we publish openly with a defensible audit trail” is a phased program, not a rewrite. The cadence:
Discover
Inventory the existing open feeds — download URLs, public services, embedded maps, partner integrations. For each feed, identify the producing department, the legal basis for publication, and the known consumers. Most agencies are surprised by how long this list is and by how little of it is documented anywhere centrally. The deliverable is a written inventory.
Architect
Design the gateway topology, the consumer registry schema, the audit retention policy per dataset, and the cutover sequence. Decide which feeds go first and which can run in parallel during migration. Produce an architecture document and a cutover plan that names every existing consumer to be migrated.
Build
Stand up the gateway in production, behind a feature flag if necessary, and migrate feeds one at a time. Each migrated feed gets its own consumer registry entries, rate limits, and audit retention policy. Avoid big-bang migrations — they fail public-procurement scrutiny and they fail consumers.
Deploy
Cut consumers over to the new gateway URLs with explicit parallel-run windows, train operators, and establish ongoing review cycles for the audit log. The deliverable is an agency that operates its own open data perimeter, not a dependency on the integrator.
Where Rodosto Fits
Rodosto Teknoloji designs and builds governed open data perimeters on top of existing ArcGIS Enterprise deployments for municipalities, regional authorities, central-government agencies, and private operators that publish geospatial data to partners or the public. The work is the same in every case: an inventory of what is already exposed, a gateway that brings every outbound request under one consumer registry, an audit trail that answers compliance questions in one query, and an operational handoff that leaves the agency running its own platform.
If your agency publishes geospatial data and the architecture above does not match what you have today, that gap is the work.
Governed open data is geospatial data published openly to external consumers while preserving the publishing agency’s ability to identify each consumer, audit each request, enforce rate limits, and revoke access on schedule. The data is just as accessible as ungoverned open data — the agency simply has the operational evidence that ungoverned publishing does not produce.
In well-tuned deployments the proxy overhead is sub-millisecond — well below any threshold that human users or downstream systems perceive. Rodosto’s reference deployments display the proxy-vs-direct latency on the operator dashboard so the figure is verifiable on the agency’s own infrastructure.
Governed open data is not protected — anyone who registers an application token can consume it. The governance layer exists for the publisher’s benefit: per-consumer audit, rate limits, lifecycle, and the ability to detect anomalous consumption patterns. The consumer experience is unchanged from any other open feed.
Retention is configured per dataset and per regulatory context. Low-sensitivity layers are commonly retained for thirty to ninety days. Layers that touch legal, regulatory, or environmental review are retained for one to ten years. Audit retention is automated through a scheduled prune job — not by manual log rotation.
Yes. The standard cadence is to run the existing open URL and the gateway-proxied URL in parallel for an explicit migration window, register the known consumers against the new gateway URL, and decommission the legacy URL only after the migration window closes. This is the cutover model Rodosto uses on every engagement.
Proxy Token Manager is the perimeter product that implements the gateway, audit, rate-limiting, and consumer-onboarding behavior described here. The Municipal GIS Playbook is the broader architecture that an open data perimeter sits inside. This post is the outbound chapter — how the same internal architecture meets the public.
