Case study · Government

An on-premise web GIS for a municipality

How a city administration asked for a new web GIS client on open source, entirely on its own infrastructure, and how we shaped the answer: right-sized, secure and independent of any vendor.

Talk to us
At a glance

The Municipality and its GIS

The Municipality runs its spatial data on QGIS Server and PostGIS, with a web client that staff use every day for viewing, querying and editing. A new national data regulation for settlement planning now prescribes the data model the city has to deliver, and the existing client has to be replaced and developed further.

named users, sized for 500
300
object types prescribed by the national data model
190
agreed recovery time target (RTO)
72 h
licence fees for the whole stack
0
Requirements

What the Municipality asked for

  • Everything on its own premises

    No cloud service in any layer: not for running, not for backups, not for monitoring. Data sovereignty is non-negotiable.

  • Hundreds of layers, fast

    Projects with several hundred layers and rich symbology that must still respond within seconds.

  • Editing with rules

    Role-based editing against a prescribed data model, with audit trails at application and database level.

  • Container platform

    Components that run and scale separately on a Kubernetes-based platform, deployed through Git.

  • Security and continuity

    Independent penetration test, documented backup and disaster recovery, a security plan for the national information security class.

  • Accountable support

    Service levels with response and fix times, a flexible term, and knowledge transfer so the city can run it itself.

Our answer

Six decisions that shaped the proposal

  • 1

    Build on proven open source

    QGIS Server, PostGIS and a mature open web client cover almost every requested function out of the box. We customise instead of reinventing, and hand over the full source code with the right to extend it, so the Municipality can change supplier at any time.

  • 2

    Honest about what is open

    Every component and licence was listed. Where a component had a restrictive licence or an uncertain future, we proposed a fully open alternative. The result is a stack with no licence fees and no mandatory subscription.

  • 3

    Availability sized to the need

    The system serves staff during office hours, and the Municipality set a 72 hour recovery target. We offered one architecture in two sizes: a minimal single-node setup that meets that target with off-site daily backups, and a three-node, automatic-failover setup for the day the needs grow. See high availability.

  • 4

    Complete the functions, simplify the parts

    The platform must provide secrets management, telemetry, GitOps deployment and scaling, but not necessarily with the heaviest product for each. We priced the full set and a simplified variant that keeps every function with fewer components to operate.

  • 5

    Data quality built into the editing

    Forms, mandatory fields and validation follow the prescribed data model, and edits are traceable at application and database level. Existing projects, styles and data are migrated into that model, supported by our AI-assisted ETL where it saves effort.

  • 6

    Support that fits a public budget

    A yearly business-hours support plan, a development hour budget the city can scale up or down, optional round-the-clock on-call for critical faults, contract-length discounts, and a closing knowledge transfer. See support and operations.

Where we gave advice

Workflows first, infrastructure in proportion

Two points we raised before quoting, because they decide the value of the project:

  • Workflow-centred design. A general toolbox lets everyone do everything. A client built around the city's real tasks, such as planning submissions or road records, means fewer steps, fewer data errors, simpler roles and acceptance that can be measured. The Municipality chose a general client first and left the workflows for a later phase. The architecture keeps that path open.
  • Proportionate infrastructure. A full high availability, round-the-clock design can cost a multiple of the application itself. We recommended setting the protection level from the system's criticality and security class, instead of designing for the highest level up front.
Delivery

Five to six months from contract to go-live

  • 1

    Survey and proof of concept

    Analyse a representative sample of projects and layers, and prove performance with hundreds of layers early.

  • 2

    Platform and automation

    Set up the container platform and Git-based deployment, in parallel with the survey.

  • 3

    Build and migrate

    Three sprints of customisation and testing, then migration of projects, styles, forms and users.

  • 4

    Prove and hand over

    User acceptance, load test, independent penetration test, training, go-live and a year of warranty.

Larger cities

The same approach, scaled up

A county seat or a capital district has the same building blocks, only more of them. What changes:

  • More users and departments: thousands of accounts across planning, roads, utilities, environment and the registry, each with its own roles
  • Public and 24/7 services: open data portals, citizen maps and emergency mapping need the full high availability design, not the minimal one
  • Integrations: document management, permitting and customer service systems connected through standard services
  • Workflows: specialised applications for the city's main processes on the same platform
  • Shared data infrastructure: metadata catalogue and standard services so that agencies and neighbouring municipalities can interoperate

Because the stack is open source, a larger city pays for engineering, not for more seats.

Infrastructure and government

Planning a web GIS for your city?

We will review your requirements and tell you what is needed, and what is not. The first consultation is free.

Talk to us