Skip to main content

Hapū GIS blueprint

For a small hapū GIS, the strongest architecture is usually the simplest one the people doing the mahi can understand, sustain and carry forward. Start with kaupapa, people, relationships and kaitiakitanga. Then choose the technology.

The point is not to make a hapū look like a corporate IT department. It is to make sure the system remains useful to whānau and kaitiaki, keeps whakapapa and source context attached to information, and does not disappear when the original GIS person leaves.

Start with the kaupapa​

Before choosing software, make visible:

  • what the GIS is for and who benefits
  • the whānau, hapū, kaitiaki and knowledge-holder relationships relevant to the mahi
  • how decisions about important information are already made
  • which information needs different versions or access patterns
  • who will look after the system day to day
  • who else can recover or continue it
  • annual operating cost
  • review cycle
  • what happens when current funding or kaimahi change

This is enough for many small organisations. There is no need to invent an extra ceremonial governance layer around ordinary technical administration.

Pattern 1 — small file-based GIS​

Suitable where one or two people edit modest data volumes and simultaneous editing is not important.

Conceptual flow

Working controls​

  • hapū or organisation holds the working folder and any service accounts
  • source, whakapapa and provenance are recorded where they help explain the data
  • different shared/public versions are clearly named
  • at least two people know where the data and backups are
  • one short runbook explains how to recover and hand over the system

Main weakness​

File copies can proliferate. Good backup and version discipline matter more than adding a complicated platform.

Pattern 2 — shared hapū GIS​

Suitable where several people edit, account roles matter or web/mobile systems need a central source.

Conceptual flow

The important feature is not PostGIS. It is that the hapū understands where the working information sits, how different versions are produced, where copies go and how the system can be recovered.

Keep the platform relationship with the hapū​

Where practical, the hapū or its organisation should hold the relationship for:

  • domain
  • GIS/cloud organisation or tenant
  • billing
  • password/secrets vault
  • main database or file repository
  • independent archive
  • supplier contract
  • documentation

A consultant can administer these without becoming the only person who can access or move them.

Control also means understanding what is held. A technically complete archive with no provenance, kōrero or explanation may be much less useful to future kaimahi than a smaller well-documented one.

Access patterns​

A project may need only two or three access patterns. A more complex one may use examples such as:

  1. public
  2. public generalised
  3. hapū internal
  4. named working group
  5. purpose-specific external copy
  6. tightly restricted
  7. information deliberately kept outside the digital system

These are examples, not a policy template. Combine them where the real-world use is the same.

Annual operating review​

Once a year, check the ordinary things that make the GIS durable:

  • the kaupapa is still current and the system is still useful
  • the people and relationships around important information are still understood
  • at least two people can recover the system
  • backups restore
  • domain and licences renew correctly
  • supplier contacts remain current
  • public/shared versions still match their intended purpose
  • old external accounts have been removed where projects ended
  • a complete export still works
  • costs remain affordable
  • important access notes and context are still understandable
  • obsolete copies have been dealt with
  • another kaimahi could understand and continue the system if current staff changed

When to stay small​

Remain with QGIS/GeoPackage or an equivalent simple arrangement where a shared database does not produce enough benefit to justify the extra administration.

Simplicity can strengthen rangatiratanga when the hapū can understand and recover the whole system. A small system that whānau can sustain may serve the kaupapa better than an impressive platform that only an external specialist understands.

When managed services help​

Managed hosting can be useful where people need reliable remote access and nobody wants to patch servers and databases. Compare services by the real operating questions: where information is hosted, who administers accounts, what exports exist, what it costs and how the hapū would move later.

See Should our hapū use the cloud? and Cloud is not one thing.

Budget for people and continuity​

Over time, administration and support can cost more than raw storage. Budget for:

  • training and whakawhanaungatanga around the system
  • paired administration
  • metadata and provenance
  • backup testing
  • supplier management
  • data review
  • migration
  • succession and handover

See Ten-year cost models and GIS succession.

Last reviewed: 26 August 2026

Last updated on