Skip to main content

Publishing draft and final maps

Draft maps are necessary. They are how you test ideas, check data, and hold kōrero before decisions are made. The problem is that drafts often escape. A draft map can end up in emails, minutes, screenshots, and shared drives, then later gets treated as truth.

This page sets out practical ways to publish drafts safely, turn them into final maps with confidence, and avoid confusion over which version is correct.

A simple risk

If a draft map is good enough to be misunderstood, it is good enough to cause problems.

Why drafts go wrong​

Drafts usually become risky for three reasons:

  • the map looks polished, so people assume it is final
  • the map is shared without context, so the purpose gets lost
  • the data changes, but old copies keep circulating

Make the difference visible​

Do not rely on filenames alone. Put the status on the map.

Add a clear status line in the layout, near the title:

  • DRAFT for kōrero
  • DRAFT for review
  • FINAL approved
  • SUPERSEDED do not use

Include the date and version on the map face:

  • Date created
  • Date published
  • Version number

If you publish both a PDF and a web map, ensure they carry the same status and version.

Use simple status stages​

Keep stages few and clear. These work well in most Māori GIS contexts:

  1. Working draft
    Internal working map. Not shared outside the mapping team.

  2. Review draft
    Shared to a small group for checking and feedback.

  3. Engagement draft
    Designed for hui, wānanga, and kōrero. Generalised and safe for photos.

  4. Final
    Approved for the stated purpose. Locked, archived, and referenced as the current version.

  5. Superseded
    Old versions that must not be used. Kept only for records.

Versioning that people can follow​

Use a version system that is readable by non-technical users.

A practical pattern:

  • v0.1, v0.2 for working drafts
  • v0.9 for near-final review
  • v1.0 for first final release
  • v1.1, v1.2 for minor updates
  • v2.0 when the meaning changes (new scope, new boundary, new method)

If the map is linked to a decision, treat any change as important and publish a new version with a short change note.

Filenames that reduce mistakes​

Use a filename pattern that sorts well and carries enough context.

Example pattern:

  • YYYY-MM-DD_topic_area_status_vX.Y.pdf

Example:

  • 2026-02-05_mahinga-kai_rohe-a_draft_v0.9.pdf
  • 2026-02-12_mahinga-kai_rohe-a_final_v1.0.pdf

Avoid “final-final”, “new”, “latest”, and “use-this-one”. Those always fail over time.

Where drafts should and should not live​

Draft control is mostly about where files live.

Recommended separation:

  • Working drafts: private project folder, restricted access
  • Review drafts: a shared folder with a short purpose note and expiry date
  • Final maps: a single “Published” location, read-only if possible
  • Superseded: archive folder, not mixed with current work

If you use SharePoint or Google Drive:

  • use a single authoritative folder for finals
  • do not email attachments if you can share links instead
  • limit who can edit final folders

Publishing to a hui or engagement setting​

Draft maps for hui need extra discipline because photos and screenshots happen.

If it is a hui draft:

  • remove or generalise sensitive detail
  • add “Draft for kōrero” on the map face
  • include a short “What this is” line
  • include a short “What this is not” line

Example text to place under the title:

  • This map supports kōrero and may change after feedback.
  • This map is indicative and should not be used for operations or enforcement.

Review workflow before calling something final​

A final map is not perfect. It is fit for purpose and agreed.

A practical Māori GIS review workflow:

  1. Technical check
    Projection, scale, labels, legend, data joins, missing layers, wrong symbology.

  2. Content check
    Is it saying the right thing, in the right way, for the kaupapa.

  3. Tikanga and sensitivity check
    Are we revealing anything that could cause harm, pressure, or loss.

  4. Decision check
    Who has authority to approve this output for the stated use.

  5. Publish and archive
    Publish the final, archive the draft set, record what changed.

Timebox review

For drafts, set a review window. After that date, the draft expires and should not be reused.

A detailed checklist for drafts​

Use this before sharing any draft outside your mapping team.

Purpose and context:

  • purpose is written in one sentence
  • intended audience is clear
  • status is on the map face (Draft for review, Draft for kōrero)

Trust markers:

  • date and version on the map face
  • data sources listed in short form
  • limitations stated (indicative, incomplete, assumptions)

Safety:

  • sensitive locations removed or generalised
  • attributes checked for identifying detail
  • screenshots of the map would still be safe if shared

Usability:

  • readable at A4
  • legend short and obvious
  • labels not tiny
  • enough reference features to orient (roads, rivers, marae where appropriate)

A detailed checklist for finals​

Use this before publishing a final map.

Accuracy:

  • correct layers, correct extent, correct coordinate system
  • no broken joins or missing features
  • any calculations or classifications double-checked

Meaning:

  • title and purpose match the decision it supports
  • symbology matches what people will assume (no misleading colours or implied certainty)
  • any boundaries that are approximate are labelled as such

Governance:

  • approval recorded (who approved, when, and what it covers)
  • sharing level stated (internal, restricted, public)
  • final location is read-only or controlled

Records:

  • final version archived
  • change note saved (what changed since last published version)
  • superseded versions moved out of circulation

Handling corrections and updates​

If you discover an error after publishing:

  • publish a corrected version with a new version number
  • write a short correction note in plain English
  • remove or clearly label the old version as superseded
  • notify the same audience who received the earlier version

A correction note can be as simple as:

  • What changed
  • Why it changed
  • What this means for decisions already made

When not to publish a draft​

Do not publish a draft if:

  • it includes sensitive locations that cannot be safely generalised
  • the map is likely to be treated as enforcement or legal truth
  • the data quality is too weak to support kōrero without harm
  • you do not have agreement on sharing level or audience

In those cases, do an in-person briefing, use a more general map, or publish a non-spatial summary first.