Last reviewed: 16 August 2026
What should an iwi GIS actually contain?
The answer is not everything about the iwi.
A GIS should contain the spatial information needed to support agreed kaupapa. It should not become the default warehouse for every piece of Māori knowledge simply because maps make information easy to find.
A useful way to build an iwi GIS is in layers of maturity.
Core kete
This is enough for many organisations to begin useful work.
Familiar place and orientation
Useful layers may include:
- marae
- awa, roto and coastlines
- roads and access context
- maunga and other major landscape features
- approved ingoa wāhi
- imagery and terrain
These help people orient the map in familiar geography.
Whenua context
Depending on the kaupapa:
- Māori land blocks
- cadastral parcels
- legal roads and access corridors
- public conservation land
- Crown land context
- council planning zones
Keep these representation types distinct. A parcel is not a rohe. A Māori land block is not the whole relationship with whenua.
Taiao context
Useful public layers include:
- catchments
- rivers and streams
- wetlands
- land cover
- soils and land-use capability
- hazards
- biodiversity or habitat information where appropriate
- climate and coastal information
See Taiao.
Local working kete
Once people are using GIS for actual mahi, local information becomes more important than adding more national datasets.
Examples include:
- restoration projects
- monitoring sites
- consent review records
- access issues
- marae infrastructure
- whānau or trust projects
- papakāinga planning areas
- locally confirmed names
- field observations
- project boundaries
This is where the iwi GIS becomes specific to the organisation rather than a copy of government open data.
Cultural and historical information
This needs a separate decision.
Do not assume the next maturity step is to import every cultural site, oral history, whakapapa record and scanned document into the geodatabase.
A better model may be:
- GIS stores an approved place reference
- a controlled archive stores the source material
- a relationship table records the connection
- access conditions travel with the record
- public maps use a reduced derivative
Some information may never belong in GIS.
See Mātauranga Māori and GIS and Things GIS cannot represent well.
Governance information
A mature GIS needs to know more than geometry.
For important datasets, record:
- kaupapa and intended use
- data authority or kaitiaki role
- source and provenance
- sensitivity
- allowed audiences
- restrictions on reuse
- review date
- status
- who maintains the layer
This can be lightweight. The point is that a future mapper should not have to guess why the layer exists or who can approve its use.
Operational information
Where GIS supports everyday service delivery or projects, it may contain:
- work sites
- assets
- inspections
- restoration actions
- consents
- hazards
- routes
- monitoring results
- project status
Keep operational data separate from cultural information when they have different access and governance needs.
A field crew does not need access to every restricted cultural layer merely because both datasets are stored in the same GIS platform.
Publishing derivatives
Do not publish the source database directly.
Create purpose-specific outputs such as:
- hui maps
- governance maps
- partner extracts
- public web layers
- StoryMaps
- dashboards
- static PDF maps
Each derivative should contain only the features and fields needed by that audience.
See Publishing Māori GIS maps safely.
What a mature iwi GIS may add
Only where the organisation can sustain it:
- shared spatial database
- controlled web GIS
- mobile field collection
- automated updates from trusted public services
- imagery and LiDAR libraries
- map and data catalogue
- versioned publishing workflows
- role-based access
- backup and recovery processes
- integration with document or records systems
- training and succession plans
A technically mature system with nobody able to maintain it is not mature in practice.
Layers that need extra caution
Think carefully before centralising:
- detailed whakapapa
- whānau addresses
- individual health or social data
- precise wāhi tapu or urupā locations
- sensitive mahinga kai locations
- locations of vulnerable taonga species
- access routes that could enable trespass or harm
- information shared for one hui or project only
The question is not whether GIS can store them. It can. The question is whether the organisation should create that concentration of information and what protections would be required.
A useful catalogue structure
A small organisation might organise maintained datasets by kaupapa rather than software type:
01_Wāhi_and_ingoa
02_Whenua
03_Wai_and_taiao
04_Marae_and_community
05_Hazards_and_resilience
06_Projects_and_mahi
07_Planning_and_external_systems
08_Restricted
09_Publishing_views
The exact categories are less important than having a structure people can understand.
What not to treat as the core
Avoid designing the iwi GIS around:
- whatever data the council happened to give you
- the layers that came with a consultant's project
- the default Esri or QGIS folder structure
- a national data catalogue
- every available open dataset
- a statutory reporting requirement that may disappear in two years
Those may be inputs. They should not define the kaupapa.
A yearly test
Once a year, ask:
- Which layers are actually used?
- Which have no known owner or purpose?
- Which are stale?
- Which sensitive layers could be reduced or removed?
- Which public datasets should be refreshed rather than stored forever?
- Can more than one person maintain the important projects?
- If funding ended tomorrow, which parts would still be sustainable?
A smaller, well-understood GIS is often stronger than a huge catalogue nobody trusts.