Map sharing and data access

Sharing a map or dataset changes where the information sits and who can copy, analyse or reuse it. The useful questions are practical: what does the recipient need, what version best serves that purpose, what happens to copies and what context should travel with the information?

Choose the form from the purpose

Before sending a map or dataset, ask:

• What is this sharing meant to help someone do?
• What level of detail is actually useful?
• Does the recipient need editable data or only the result?
• What happens to copies after the immediate work is finished?
• Will the information be joined with other datasets?
• What derived outputs might be created?
• How long will the information remain useful?

A request for the layer does not always mean the master dataset is the best response.

Make conditions explicit when they matter

Where information is shared with particular expectations, record those expectations with the transfer rather than leaving them in somebody's email or memory.

Depending on the kaupapa, useful notes can cover:

• intended purpose
• people or roles included in the work
• onward sharing expectations
• whether exact geometry needs to be retained
• whether the information will be combined with other datasets
• AI, model training or automated processing if relevant
• review of derived outputs where that is part of the project
• return, deletion or archive arrangements
• review or expiry date

A technical file licence and the practical relationship around the data are not necessarily the same thing.

Choose the useful representation

The person receiving the information may need the answer rather than every source field behind it.

Possible forms include:

• a PDF rather than an editable layer
• a generalised polygon rather than an exact working geometry
• a view layer rather than the source database
• selected fields rather than the full schema
• counts or categories rather than individual features
• a temporary account rather than a permanent copy

Different audiences can legitimately need different representations of the same underlying mahi.

Internal access

Internal is not one natural technical boundary.

A large Māori organisation may include people with very different roles and reasons for using information. Named roles or groups can make the system easier to understand than one broad internal folder.

Useful practices include:

• separating working data from publication outputs
• role-based access where it helps
• dated, versioned files
• regular review of dormant accounts
• clear responsibility for important datasets
• avoiding accidental broad access to information intended for a smaller working group

See Access and security.

Trustees, boards and governance bodies

People making decisions may need a clear map, summary or briefing without needing edit access to the whole GIS.

Prepare the representation for the decision being made. A concise map, in-room view or supporting appendix can sometimes communicate the issue better than a full export of the working dataset.

Councils and Crown agencies

Public agencies may need Māori-held spatial information for planning, infrastructure, environmental work, statutory processes or joint projects.

Useful things to clarify are:

• the operational or statutory purpose
• what information will meet that purpose
• how it will be stored and linked
• whether it will become an official record or public dataset
• what other teams or systems may receive it
• what happens when the immediate purpose ends

A purpose-built derivative can be easier for both sides to understand than sending the whole internal source layer.

See Government and councils.

Consultants and contractors

Consultants often need enough detail to complete technical work without needing permanent ownership of the organisation's whole GIS environment.

Useful arrangements cover:

• organisation-owned accounts where practical
• storage
• access
• subprocessors
• AI use where relevant
• copies and backups
• derived outputs
• documentation
• return or deletion
• handover and removal of access

See Consultants and contracts.

Researchers and other partners

Research relationships can create useful collective benefit. The practical questions are similar to other data-sharing relationships:

• what questions are being investigated
• what datasets will be linked
• how interpretation and publication will work
• what capability or benefit returns to the people involved
• what future reuse is expected
• what happens to working copies after the research

Research ethics approval is one institutional process. It does not replace a clear understanding between the people and organisations actually sharing the information.

Hui, wānanga and wider kōrero

For hui and wānanga, prepare the map for the kaupapa and the people in the room.

A printed map, projected web map, generalised layer or detailed working view can each be useful. If photographs, copies or later circulation matter, make that clear as part of the session rather than assuming everyone treats the material the same way.

See Maps for hui and wānanga.

Web sharing

Web platforms make copying and reuse easy, which is often exactly why they are useful.

When publishing or sharing through a web platform, check:

• group and role membership
• anonymous access
• feature export
• attribute tables
• popups
• attachments
• search indexing
• dependent apps and embeds
• item metadata and thumbnails

Build web maps from an audience-specific view or publication layer where that makes the product easier to understand.

ArcGIS patterns

In ArcGIS Online or Enterprise, a common pattern is:

1. keep the working source layer in the group that maintains it
2. create a view for the particular audience or purpose
3. remove or filter fields and features in that view where useful
4. build the web map from the view
5. share the view and map to the intended group or public audience
6. review export and attachment settings

The map and the underlying layer can have different sharing settings, so check both.

When a different representation may be better

A different map, summary or dataset may be more useful when:

• the purpose is still unclear
• information is contested or still being checked
• the requested precision adds no value to the task
• the recipient only needs a summary or result
• the likely combination with other datasets changes what the information reveals
• storage or onward-sharing arrangements are still being worked out

Not in that form can be a practical design answer rather than a simple yes or no.

Keep a sharing record when it helps

For important transfers, record enough to reconstruct what happened later:

• kaupapa and purpose
• what was shared
• what representation or generalisation was used
• with whom or what organisation
• date
• source or decision context
• relevant sharing notes
• review or expiry date
• expected return, deletion, archive or next step

This helps future kaimahi understand where copies may exist and why they were created.

Final check

Before sharing, ask whether the arrangement will still make sense if the recipient changes staff, merges systems or wants to reuse the data later.

If the whole arrangement depends on one person remembering an informal conversation, write down enough context for the next people involved to understand it.

Last reviewed: 26 August 2026