Skip to main content

Publishing draft and final maps

Draft maps are useful because they let people question, correct and reshape a representation before it becomes fixed. In Māori GIS work, a draft should create room for kōrero rather than quietly turning an early technical interpretation into the thing everybody is asked to approve.

The practical problem is that drafts travel. Screenshots, emails and meeting packs can make an indicative map look final years later.

Make status visible​

Put the status on the map itself, not only in the filename.

Useful labels include:

  • WORKING DRAFT
  • DRAFT FOR KŌRERO
  • DRAFT FOR TECHNICAL REVIEW
  • APPROVED FOR [PURPOSE]
  • SUPERSEDED — DO NOT USE

Final by itself can be misleading. A map can be final for one kaupapa and completely inappropriate for another.

Include the date and version on the map face.

Use stages that describe what is happening​

A simple set can be:

  1. Working draft — internal technical work.
  2. Draft for kōrero — prepared for hui, wānanga or another appropriate review process.
  3. Draft for a specific decision — close to the required representation but not yet authorised for that purpose.
  4. Approved for stated purpose — accepted through the appropriate decision path for the use written on the map.
  5. Superseded — retained for record but no longer current.

Avoid treating approval as one universal state.

A draft for hui is not a survey instrument​

A map taken to hui may be deliberately incomplete so people can question it. Do not interpret every comment, annotation or silence as formal validation.

Be clear about:

  • what is open for discussion
  • what is already established
  • what is only one source or interpretation
  • whether any mark-up will be retained or digitised
  • what further mandate is needed before the map changes status

See Maps for hui and wānanga.

Versioning​

Use a simple version system people can follow, for example:

  • v0.1, v0.2 for working drafts
  • v0.9 for a near-final representation
  • v1.0 for the first approved version for a stated purpose
  • v1.1 for minor corrections that do not change meaning
  • v2.0 where the representation or underlying decision changes substantially

The version number is less important than the visible status and purpose.

File handling​

A practical separation is:

  • working drafts in the mapping workspace
  • hui/review versions in a clearly labelled review location
  • approved versions in one controlled published location
  • superseded versions in an archive

Do not mix current and superseded maps in one folder and expect filenames to do all the work.

Review different things separately​

A map can pass technical QA and still not be ready for use.

Technical check​

Check projection, geometry, data versions, calculations, labels, legend and readability.

Kaupapa check​

Does the map actually support the question or decision? Is anything important missing because the GIS frame was too narrow?

Meaning and tikanga check​

Are names, places, relationships, sensitivity and representation appropriate? Does the map imply a certainty or authority it does not hold?

Mandate for use​

Who or what process can authorise this particular representation for this particular purpose?

That may differ between an internal working map, a council submission and a public StoryMap.

Do not force one account into a final map​

A map can be final while still showing uncertainty, overlap or different accounts.

Where sources or kōrero differ, preserve the difference where that is the honest representation. Final should not mean all complexity removed.

Before sharing a draft​

Check:

  • kaupapa and intended use are written on the map
  • status and date are visible
  • sensitive detail is appropriate for the people who will receive it
  • the map is safe if photographed or forwarded
  • boundaries and models are not shown with false certainty
  • source and provenance notes are sufficient
  • people understand what will happen to any kōrero generated around the draft

Before approving a map for use​

Check:

  • technical QA is complete
  • the map serves the stated kaupapa
  • the representation has been considered through the appropriate local or organisational process
  • publication or sharing authority is clear for this specific use
  • restrictions and limitations are visible
  • an approved record is stored
  • the next review point is known where the map is expected to change

Corrections​

If an error is discovered:

  • issue a corrected version
  • state what changed
  • explain whether the correction affects decisions already made
  • mark the earlier version superseded
  • notify the same relationship or audience that received the earlier version where practical

If the problem is not a technical error but a question of meaning, mandate or representation, return to the appropriate kōrero rather than treating it as a GIS edit only.

When not to publish a draft​

Do not circulate a draft where:

  • sensitive information cannot be represented safely
  • the map is likely to acquire legal or enforcement meaning it was not prepared to hold
  • the data is too weak to support useful kōrero
  • mandate for the sharing itself is unclear
  • an in-person or non-spatial discussion would better serve the kaupapa

A map does not have to be distributed merely because it exists.

Keep versions connected​

The wider Publishing Māori GIS maps section covers audience and format choices. Use Attribution and sources to carry provenance into the output and Sensitive locations when a shared version needs different spatial detail from the working map.

Last updated on