Skip to main content

Publishing maps for reports, plans, and submissions

Maps in reports and submissions have a long life. They get printed, photocopied, forwarded, and quoted. They can end up in council files, hearings, court records, and future plan changes. That means the map needs to be readable, honest about limits, and clear about what it does and does not claim.

This page is a practical guide for producing maps for:

  • iwi and hapū management plans
  • environmental plans and monitoring reports
  • submissions on plans and policies
  • consent applications and supporting documentation
  • technical evidence and appendices
Treat report maps as permanent

If you would be uncomfortable seeing the map in five years with no extra context, change the map now.

Start with the map’s job​

Every report map should have one main job. Common jobs include:

  • show location and context
  • describe a rohe or area of interest
  • show constraints and opportunities
  • summarise monitoring results
  • show change over time
  • support an argument in a submission
  • support conditions or recommendations

Write the job in one sentence. Then design the map to serve that job only.

The difference between a map and evidence​

A map can be:

  • an illustration to support kōrero
  • a summary of data
  • a formal statement about boundaries or locations
  • an analytical output (model results, classifications, risk scoring)

Be explicit which one it is. If it is not evidence, do not let it look like evidence.

Use plain language on the map:

  • “Indicative map for context”
  • “Draft analysis, not validated”
  • “This map summarises publicly available data”
  • “Boundaries are approximate”

Layout choices that survive printing​

Report maps often end up as:

  • black-and-white prints
  • reduced size (shrunk to fit)
  • photocopies of photocopies

Design accordingly.

Practical rules:

  • avoid thin pale lines
  • avoid subtle colour differences
  • avoid legends that require colour to interpret
  • make labels larger than you think you need
  • keep the map uncluttered

If you can, test print a page at the size it will appear in the report.

What every report map should contain​

Use this as a minimum standard.

  • Clear title that states what the map shows
  • Map purpose line (one sentence)
  • Legend (short, only what is used)
  • Scale bar (prefer scale bar over ratio)
  • North arrow only if orientation could be confusing
  • Data sources (short form)
  • Date of map creation or publication
  • Author or organisation name
  • Version number if it may be updated

Optional but often useful:

  • inset map for regional context
  • coordinate grid only if needed for field location or referencing
  • notes on limitations and assumptions

Place names and bilingual naming​

Report maps should use place naming carefully.

Good practice:

  • use Māori names where known and appropriate
  • include macrons where possible
  • if a place is commonly known by two names, consider showing both
  • be consistent across the report

Avoid:

  • mixing spelling styles across maps
  • using informal nicknames in formal submissions
  • copying labels from datasets without checking correctness

Rohe and boundaries​

Rohe and takiwā are not always hard lines. They may be shared, overlapping, seasonal, or held in kōrero rather than in geometry.

When publishing rohe:

  • describe the boundary type (indicative, administrative, customary, Treaty settlement area, consultation area)
  • label it clearly if it is not precise
  • avoid presenting a fuzzy boundary as a legal line

If the boundary is contested or uncertain:

  • consider a zone of interest rather than a line
  • use notes that acknowledge shared spaces

Scale and precision​

A common failure is showing too much precision at the wrong scale.

Examples:

  • showing points at 1:250,000 and implying accuracy
  • drawing a boundary line thicker than the feature it represents
  • mapping sensitive sites as exact points in a public appendix

Be honest:

  • match the scale to the reliability of the data
  • generalise where the data does not support precision
  • if the map is indicative, say so

Sensitive information in reports​

Reports and submissions are high-risk for leakage because they are widely circulated.

If sensitive locations are involved:

  • publish generalised areas rather than points
  • remove identifying attributes from labels and tables
  • keep sensitive layers out of appendices unless the document is restricted
  • consider separate restricted appendices with controlled distribution
  • consider describing sensitive information in words without mapping it

Write a short protection note on the map:

  • “Sensitive locations are generalised to protect taonga and tikanga.”

Data sources, licensing, and attribution​

Report maps should make it easy to understand what data was used.

Minimum source list should include:

  • who published the dataset (organisation name)
  • dataset name or layer name
  • date accessed or dataset version if known

If the report is public:

  • ensure you have the right to publish the datasets used
  • do not include restricted layers in publicly released files
  • do not include copyrighted basemaps as exported images unless permitted

Managing uncertainty and limits​

A strong report map includes limits, not just content.

Common limits to state:

  • gaps in coverage
  • known errors in source datasets
  • seasonal variation
  • modelling assumptions
  • generalisation methods used
  • date ranges (for monitoring and time-series)

Where to put limits:

  • in a short note beside the legend
  • in the figure caption
  • in a methods section with the map referenced as “Figure X”

Figure captions that reduce misinterpretation​

A good caption does real work. It should explain:

  • what the map shows
  • why it is included
  • any important limits
  • what should not be inferred

A useful caption pattern:

  • “Figure X shows … to support … The map is indicative because … Sensitive locations are generalised.”

Submission maps and persuasion without distortion​

Submission maps often support an argument. That is normal. The line is crossed when the map misleads.

Keep it defensible:

  • do not hide relevant context
  • do not use dramatic colour ramps that imply certainty
  • do not overstate model outputs
  • keep methods transparent

If you used analysis:

  • state the method at a high level
  • state the main inputs
  • state the main limitations

Technical appendices​

If your main report needs to stay readable, use appendices for:

  • data dictionaries
  • full metadata
  • methods detail
  • additional maps for reviewers

Keep appendix maps clearly labelled so they do not get detached and reused incorrectly.

A comprehensive pre-publish checklist​

Use this before final export.

Map purpose and audience:

  • one sentence purpose is written
  • audience is clear (public, council, internal, hearing)
  • sharing level is stated if needed

Map content:

  • one main message
  • labels readable at final print size
  • legend only includes what is in the map
  • basemap detail does not overpower the message

Accuracy:

  • correct coordinate system
  • correct layer versions used
  • joins and filters checked
  • obvious outliers checked

Boundaries and precision:

  • boundary type stated (indicative, administrative, customary)
  • scale matches data reliability
  • no false precision (over-detailed points, overly sharp lines)

Sensitivity and tikanga:

  • sensitive locations protected (generalised or removed)
  • attributes checked for re-identification risk
  • protection note included where needed

Attribution and sources:

  • datasets cited in short form
  • date accessed or dataset date included
  • licensing checked for public release

Files and records:

  • version number and date on map face
  • filenames include date and version
  • final outputs stored in a single published location
  • drafts and superseded versions archived separately

What to export​

For most reports and submissions:

  • export a PDF for inclusion in the report
  • keep the GIS project file as the working record
  • keep a read-only copy of the final layout and data list

If others will reuse the map:

  • publish a high-resolution PDF
  • consider a separate low-resolution public version for safety
  • avoid sharing raw layers unless required and appropriate

After publishing​

Once a report is submitted:

  • record exactly which version was submitted
  • store the final PDF and figure exports together
  • write a short change note if updates are needed later
  • if an update is required, publish a new version and mark the old one as superseded