Skip to main content

Attribution, sources, and metadata for published maps

Publishing a map without sources creates trouble later. People cannot judge accuracy, it becomes hard to update, and the map can be reused in ways that do not match your kaupapa.

This page shows how to add enough attribution and metadata to make your maps trustworthy and reusable, without turning the map into a wall of text.

A simple aim

Give future readers enough information to understand what the map is, where the data came from, when it was made, and what it should not be used for.

What “metadata” means on this site

Metadata is just information about the map and its data.

For published outputs, you normally want:

  • who made the map
  • when it was made and published
  • what it is for
  • what datasets were used
  • how accurate or complete it is
  • any limits, assumptions, or generalisation
  • any restrictions on sharing and reuse

You can hold full metadata in your GIS project or a companion document. The map itself only needs a light version.

Minimum attribution to include on every published map

Put this information either on the map face (small text near the legend) or in the figure caption if the map is in a report.

Minimum set:

  • Map title
  • Map author or organisation
  • Date published (or date created)
  • Version number if it may change
  • Data sources (short list)
  • Scale bar

If the map is shared outside your organisation, also include:

  • a brief limitation note (indicative, not surveyed, incomplete)
  • a sharing statement (internal, restricted, public)

Data source notes that are short but useful

A source note does not need to be perfect. It needs to be clear.

Good short-form source notes follow this pattern:

  • Publisher, dataset name, date (or “accessed date”)

Examples you can copy and adapt:

  • Basemap: LINZ, Topo50, accessed 2026-02-05
  • Parcels: Toitū Te Whenua LINZ, NZ Property Titles (parcels), accessed 2026-02-05
  • Aerial imagery: XYZ Council Open Data, 2021 orthophotos, accessed 2026-02-05
  • Rivers: Land Information NZ, Hydrography, accessed 2026-02-05
  • Marae locations: internal dataset, updated 2025-11-20

If the dataset has a version number or publication date, include it.

When you should cite the method, not just the data

If you created a derived layer, say so. Otherwise readers assume the data came from a source.

Examples:

  • “Risk classes derived by combining slope, soils, and land cover (method summary in Appendix A).”
  • “Sites generalised to 1 km grid to protect sensitive information.”
  • “Rohe boundary is indicative, drawn for engagement purposes.”

This makes your map more defensible and prevents misuse.

Licensing and reuse notes

Not all data can be republished freely. Licensing is not only a legal issue. It is a trust issue.

Practical approach:

  • For public maps, check you have permission to republish each layer and basemap in the format you are publishing.
  • For internal maps, record sources anyway. It still matters later.

If you are not sure about a dataset’s licence:

  • do not publish it publicly as an exported layer or high-resolution image
  • consider using a safer basemap or referencing it without embedding it

Keep licence notes short. Examples:

  • “Contains data licensed for internal use only.”
  • “Public version uses open data sources only.”
  • “This map may be shared within the organisation. External sharing requires permission.”

Māori data, iwi data, and tikanga notes

Some information is governed by tikanga, even if it looks like ordinary GIS data.

If the map includes iwi or hapū knowledge, or sensitive layers:

  • state the governance expectations in plain language
  • avoid implying public ownership or general reuse rights

Useful plain statements:

  • “This map includes iwi-held information. Do not redistribute.”
  • “Sensitive locations are generalised to protect taonga and tikanga.”
  • “For further detail, contact the kaitiaki.”

If appropriate, name the kaitiaki role rather than a person.

Captions versus map-face text

You can place attribution in two places:

  • on the map face (preferred for standalone maps and screenshots)
  • in the figure caption (works well for reports)

If a map might be separated from a report, put the key notes on the map face. Maps often get copied without captions.

A lightweight metadata block you can reuse

Use this as a consistent pattern on maps and in reports.

  • Title:
  • Purpose:
  • Author / organisation:
  • Date:
  • Version:
  • Sources:
  • Notes / limits:
  • Sharing:

Keep each line short. If you need more detail, put it in an appendix or a companion page.

Common mistakes and how to avoid them

Mistake: “Source: Google”
Fix: Name the dataset and publisher, not the search tool or map viewer.

Mistake: No date
Fix: Always include at least a published date. Data changes.

Mistake: Lists of 20 layers in tiny text
Fix: List only the key datasets on the map. Put the full list in a companion document.

Mistake: Releasing a public map that includes restricted layers
Fix: Create a public-safe version with only open or permitted layers.

Mistake: Implying certainty that the data does not support
Fix: Add a short limitation note. If the boundary is indicative, say it.

A comprehensive pre-publish checklist

Sources:

  • key datasets listed with publisher and dataset name
  • dates or versions included where possible
  • derived layers labelled as derived, not as source data

Metadata:

  • title, author, date, and version on the map
  • purpose statement included for any map that may be reused
  • limitations stated (indicative, incomplete, modelling assumptions)

Licensing and governance:

  • public sharing checked against licences and agreements
  • iwi and hapū information clearly marked with expectations
  • sensitive information generalised or removed

Consistency:

  • same style used across maps in the same report or project
  • place names consistent and macrons used where possible
  • file naming includes date and version

Records:

  • GIS project and source notes saved with the published outputs
  • final outputs stored in a single published location
  • superseded outputs clearly labelled and archived

What to keep with the map, even if you do not publish it

For your own records, keep a short companion file or note that includes:

  • full dataset list and links
  • data download dates
  • processing steps
  • contact person or kaitiaki role for questions
  • any approvals for publishing

This makes it much easier to update the map later and to respond to questions with confidence.