Metadata and documentation
Metadata is not only a technical description of a dataset. In Māori GIS it can help preserve the whakapapa of information: where it came from, why it was recorded, what relationships and decisions shaped it, what the geometry represents and what later users need to understand it.
Without that context, a GIS feature can outlive the people who understand it and acquire meanings or uses it was never created to support.
Keep different kinds of provenance visible
Depending on the kaupapa, useful information can include:
- institutional source, dataset and date
- Māori-held source or source relationship where useful
- kaupapa and intended use
- decision context or project process
- what the geometry represents: exact, approximate, indicative or generalised
- intended audience and sharing context
- sensitivity where it affects handling or publication
- known uncertainty or different accounts
- review date
- kaitiaki or contact role where useful
Do not expose names, whakapapa or knowledge-holder details simply to satisfy a metadata template. Metadata should help explain the record, not create another unnecessary copy of the kōrero.
Avoid generic authority fields
A field called data_owner or authoritative_source can hide important differences.
For example:
- LINZ may maintain the cadastral geometry
- a council may maintain a planning overlay
- an iwi or hapū may hold locally developed information about whenua, wai or ingoa wāhi
- a whānau or named group may carry particular kōrero or source relationships
Record what the source is authoritative for, or what relationship matters to this record, rather than forcing all of these into the same category.
See Authoritative for what? and Whakapapa of data.
Record decisions as well as sources
Where a map or layer has been deliberately simplified, masked, withheld from one output or prepared for a particular audience, record why.
Useful notes include:
- why the information was collected
- why GIS was chosen as the representation
- what was excluded from this version
- what was generalised
- what further kōrero is held elsewhere
- what this version was prepared for
- what change in purpose or audience would justify another review
This helps the next kaimahi avoid assuming that a missing attribute was an oversight or that a public layer is the complete record.
Language and naming
Use names and descriptions that retain meaning.
- use correct ingoa wāhi and macrons
- distinguish official, historical and local naming where needed
- avoid labels that turn relationships into generic
assets,sitesorstakeholderswithout good reason - state when a boundary is indicative or created for a particular kaupapa
Neutral-sounding language can still carry assumptions. Use the wording that most accurately describes the information.
See Place names and Sites and places.
Keep documentation with the data
Metadata should survive export, staff change and platform migration.
Where practical:
- keep a readme with each important project or dataset
- include essential metadata in open or portable formats
- do not leave the only provenance in one person's email
- update records when purpose, audience or representation changes
- keep enough documentation for the next kaimahi to recover and understand the work
Out-of-date metadata is a problem. Metadata stripped of relationships and context can be a bigger one.
A compact project record
For a small project, a useful minimum can be no more than:
Dataset / layer:
Source:
Source date or access date:
Kaupapa / purpose:
What the geometry represents:
Working status / version:
Audience or output this version serves:
Known limitations or different accounts:
Related source material:
Contact / project role:
That is enough to make a GeoPackage, shapefile export or web layer far easier to understand months or years later.
Continue with Provenance and source checking, Templates and registers and GIS succession.
Last reviewed: 26 August 2026