How Public, Private, and Shared Access Works

Geobble separates visibility from sharing.

A resource can be:

Public — available through Geobble's public access model;
Private — restricted to accounts with appropriate access;
Shared — access has been granted to a specific account or, for supported organisation workflows, a team.

These concepts can overlap.

For example, a Project remains private but can be shared with a collaborator. A private Collection can be shared with another account. A public Map can be accessible publicly without requiring every viewer to receive an individual share.

The basic model is:

Visibility
├── PUBLIC
└── PRIVATE

Scoped access
├── Owner / organisation membership
└── Explicit share
    ├── Viewer
    ├── Editor
    └── Admin

Understanding which mechanism you need helps avoid making a resource public when you only intended to collaborate with a few people.

Public is not the same as shared

This is the most important distinction.

Public

Public visibility answers:

Can this resource be accessed through Geobble's public access model?

It is appropriate when the resource is intentionally meant for a broad audience.

Shared

Sharing answers:

Which specific account or team should receive access, and what should they be allowed to do?

Sharing does not require making the resource public.

For example:

Private Project
      +
Share with @research-partner as Editor

allows collaboration without turning the Project into a public resource.

Private is not the same as “only I can ever see it”

A private resource is excluded from public access.

It can still be accessible through mechanisms such as:

ownership;
organisation membership;
an explicit resource share.

Conceptually:

PRIVATE

Public visitor       → no access
Owner                → access
Authorised org member → access
Shared collaborator   → access according to role

So PRIVATE should be understood as:

Do not expose this resource publicly.

not necessarily:

No other account can be granted access.

Access depends on the resource type

Not every Geobble resource uses visibility in exactly the same way.

The main cases are:

Resource: Collection · Public/private visibility: Yes · Scoped sharing: Yes · Important behaviour: Sources inherit Collection access
Resource: Source · Public/private visibility: Inherited from Collection for normal catalogue access · Scoped sharing: Access can also be resolved through resource policy · Important behaviour: Current user-facing workflow normally manages access through the Collection
Resource: Project · Public/private visibility: Always scoped rather than publicly readable · Scoped sharing: Yes · Important behaviour: Intended for working collaboration
Resource: Map · Public/private visibility: Yes · Scoped sharing: Supported by resource access model · Important behaviour: Public is the normal audience-facing publication mode
Resource: Symbol Set · Public/private visibility: Resource visibility/access model · Scoped sharing: Yes · Important behaviour: Can be shared as a reusable resource

The practical rules for the most common workflows are explained below.

Collections and Sources

Collection visibility controls normal Source visibility

Every Source belongs to a primary Collection.

In Geobble's current access model, Source access is resolved together with the access inherited from that Collection.

This means the Collection is the main catalogue-level access boundary for its Sources.

Conceptually:

Collection
├── Source A
├── Source B
└── Source C

If the Collection provides access to an account, its contained Sources can inherit that access.

This is why you should think about Collection visibility before adding or publishing Sources within it.

A public Collection makes its Sources publicly accessible through inherited access

Suppose you have:

Collection:
Cameroon Administrative Boundaries

Visibility:
PUBLIC

with:

Regions
Divisions
Subdivisions

The Sources inherit access through that public Collection.

You do not need to manage each Source as an isolated public/private catalogue object.

This helps keep related datasets under one coherent publication boundary.

A private Collection keeps normal catalogue access restricted

For example:

Collection:
Internal Survey Data

Visibility:
PRIVATE

means its Sources are not made publicly accessible merely because they have finished processing or are used in a Project.

A Source reaching:

READY

does not make it public.

Processing status and access are completely different concerns.

Changing a Collection's visibility deserves review

Before changing a Collection from:

PRIVATE

to:

PUBLIC

review the Sources it contains.

Check for:

confidential data;
personal information;
sensitive locations;
internal attributes;
licence restrictions;
redistribution restrictions;
unfinished metadata;
known quality limitations.

Because Sources inherit Collection access, changing the Collection affects more than the Collection landing page.

Share a Collection when you want scoped catalogue access

A Collection can be shared with another account without making it public.

Open the Collection and choose:

Share

Enter the account handle and select a role:

Viewer
Editor
Admin

Then select:

Share collection

This is useful when, for example, you want another organisation to work with a private dataset without publishing it openly.

Share the Collection rather than treating each Source independently

In the current user-facing workflow, Collection sharing is the practical way to provide access to the Sources organised within it.

For example:

Private Collection
"Project Monitoring Data"
      ↓
Share with @partner-ngo as Viewer
      ↓
Partner gains inherited read access
to the Collection's Sources

This keeps the access model understandable.

If several Sources belong to one collaboration boundary, sharing the Collection is usually clearer than trying to establish unrelated permissions for every dataset.

Projects

Projects remain scoped resources

Projects are working environments rather than public catalogue pages.

Geobble treats Projects differently from resources such as public Maps or Collections: a Project does not become publicly readable merely through a public-style visibility flag.

Projects remain scoped to authorised accounts.

Use sharing when another person needs access.

This reflects their intended purpose:

Project
→ analysis
→ working data
→ conversation
→ intermediate results
→ collaboration

rather than:

Project
→ public publication page

For audience-facing publication, create a Map.

Share a Project with an account

Open the Project sharing action.

For an account target:

choose Account;
enter the account handle;
select a role;
choose Share project.

For example:

Project:
Flood Exposure Analysis

Shared with:
@research-partner

Role:
EDITOR

The collaborator can then work according to the granted role without the Project becoming public.

Organisation Projects can also be shared with teams

When the owning account is an organisation, the current Project sharing interface can target a Team.

For example:

Organisation:
@planning-agency

Team:
Urban Resilience

Project:
Douala Flood Exposure

Instead of sharing the Project separately with every member, you can grant access to the relevant Team.

Select:

Team

then choose the Team and its role.

This is useful when access should follow a working group rather than one individual account.

Team access follows team membership

A team share means eligible members of that organisation team receive access through the team grant.

Conceptually:

Project
   ↓ shared with
Urban Resilience Team
   ├── Member A
   ├── Member B
   └── Member C

This makes team sharing preferable to several individual shares when the collaboration genuinely belongs to that team.

Maps

A saved Map starts private

When you use Save as Map from a Project, Geobble creates a private Map snapshot.

You can review it before deciding whether it should become public.

This gives you the sequence:

Project
   ↓
Save as Map
   ↓
PRIVATE Map
   ↓
review
   ↓
PUBLIC when ready

See How to Publish an Interactive Map for the complete publication process.

Make a Map public for an audience

When the Map is ready for open access, change its visibility to:

PUBLIC

Public Maps are intended for audience-facing geographic presentation.

This is different from sharing the underlying Project.

For example:

Private Project
      ↓
Public Map

is a normal pattern.

The audience receives the finished geographic presentation rather than access to your working Project.

A public Map does not make its Project public

Publishing a Map does not turn the underlying Project into a public collaborative workspace.

These resources have different boundaries:

Project
PRIVATE + optionally shared

Map
PRIVATE or PUBLIC

This lets you publish results while keeping working conversations, intermediate results, and Project context scoped.

Sharing roles

Explicit resource shares currently use three roles:

Viewer
Editor
Admin

These roles determine what the recipient can do with the shared resource.

Viewer

A Viewer can read the resource.

Use Viewer when the recipient needs to:

inspect the resource;
use it in an allowed read-oriented workflow;
review the work;

but should not modify it.

Conceptually:

VIEWER
→ read
→ no editing
→ no share administration

This is the safest default when collaboration does not require modification.

Editor

An Editor can read and modify the resource.

Conceptually:

EDITOR
→ read
→ write
→ no share administration

Use Editor when the collaborator genuinely needs to change the resource.

For example, an Editor on a Project may participate in the working Project rather than merely inspect it.

Do not grant Editor merely because somebody needs to see the result.

Admin

An Admin share grants stronger resource-level control.

In the current access policy, Admin-level resource access includes the capability to:

read;
write;
delete or restore the resource within the delegated resource policy;
manage its shares.

Conceptually:

ADMIN
→ read
→ write
→ delete/restore
→ manage shares

Grant this role sparingly.

If someone only needs to collaborate on content, Editor is usually the more appropriate role.

Owner is stronger than a share role

The resource owner remains distinct from Viewer, Editor, or Admin shares.

A share does not transfer ownership.

Conceptually:

OWNER
    ↓ grants
ADMIN / EDITOR / VIEWER

An Admin share receives substantial delegated control but does not become the resource owner.

For example, permanent deletion remains more restricted than ordinary delegated resource administration.

Organisation roles and resource shares are different

An organisation member can already receive resource access through their organisation role.

Organisation roles include:

Viewer;
Editor;
Admin;
Super;
Owner.

At the general resource level:

Organisation Viewer
→ read

Organisation Editor
→ create / read / update

Organisation Admin+
→ broader resource administration

An explicit resource share is therefore not always necessary for every organisation member.

Organisation membership answers a broader question

Organisation membership asks:

What can this person generally do within this organisation?

A resource share asks:

What access should this account or team have to this particular resource?

These are different scopes.

For example:

Organisation role:
VIEWER

Specific Project share:
EDITOR

can give a person stronger access to one Project than their general organisation role would otherwise provide.

When several access paths exist, Geobble resolves the strongest applicable resource role.

The strongest applicable access wins

A person may receive access through more than one path:

Public visibility
Organisation membership
Direct account share
Team share
Ownership

Geobble resolves these paths and uses the strongest applicable viewer role.

For example, if somebody has:

Organisation role:
VIEWER

but receives:

Project share:
EDITOR

their effective Project role can be Editor.

This avoids a weaker access path unnecessarily cancelling a stronger authorised one.

Shared does not mean copied

When you share a resource, Geobble grants access to the existing resource.

It does not automatically create a private copy for the recipient.

Conceptually:

Original Project
      ↓ share
Collaborator accesses same Project

not:

Original Project
      ↓
Collaborator's independent copy

This matters because edits made by authorised collaborators can affect the shared working resource.

If you need an independent version, use a workflow that explicitly creates a copy or clone where supported.

Referencing a shared Source also does not archive it into your Project

If your Project references a Source owned elsewhere, that reference still depends on access to the underlying resource.

Sharing does not silently transform it into a private archival copy owned by your Project.

If access to the original resource is later revoked, the Project may no longer be able to use it normally.

This is particularly important for long-lived collaborative analysis.

Manage outgoing shares

Geobble provides an account Sharing page for active access grants made by the account.

It can show information such as:

resource;
resource type;
recipient account or team;
granted role;
sharing date.

Supported entries on the current page include:

Collections;
Maps;
Projects;
Symbol Sets.

This provides a central place to review who currently has scoped access.

Revoke access when it is no longer needed

On the Sharing page, select:

Revoke

for the relevant grant.

Revocation removes that explicit share.

For example:

Project
Shared with @consultant as EDITOR
      ↓
Revoke
      ↓
Explicit Project grant removed

However, remember that the person might still have access through another valid path.

For example:

the resource is public;
they are an authorised organisation member;
they belong to a Team that also has access;
another applicable share exists.

Revoking one grant removes that grant. It does not override every independent access mechanism.

Sharing is not publication

Suppose you want three colleagues to review an unfinished Map.

The appropriate model may be:

PRIVATE
+
scoped access

not:

PUBLIC

Likewise, if a Project partner needs editing access, share the Project rather than publishing a Map and expecting the public Map to serve as a collaborative workspace.

Use:

Sharing for collaboration.

Use:

Public visibility for publication.

Examples

Private Collection shared with a partner

Collection:
Conservation Survey Data

Visibility:
PRIVATE

Share:
@research-partner — VIEWER

The partner can inspect the shared Collection and inherited Sources according to the granted access, while the Collection remains unavailable to the general public.

Private Project shared with a collaborator

Project:
Forest Change Assessment

Public:
No

Share:
@analyst — EDITOR

The analyst can collaborate on the Project without exposing it publicly.

Organisation Project shared with a team

Project:
National Infrastructure Review

Team:
GIS Team

Role:
EDITOR

The relevant team receives scoped collaborative access.

Public Map backed by private working material

Project:
PRIVATE

Map:
PUBLIC

Viewers receive the finished Map, not access to the private Project.

This is often the appropriate model for publication.

Choose the least access required

A useful rule is:

Give people the minimum level of access needed for the work they actually have to perform.

If somebody only needs to review:

VIEWER

is preferable to:

EDITOR

If they need to edit but do not need to manage collaborators:

EDITOR

is preferable to:

ADMIN

This reduces accidental changes and makes responsibility clearer.

Review access when the purpose changes

Access requirements can change during a Project.

For example:

Research phase
→ partner = EDITOR

Review phase
→ partner = VIEWER

Collaboration ends
→ revoke share

Do not leave elevated access indefinitely simply because it was appropriate earlier.

Check downstream access before collaboration

A Project can use several resources with different owners and access rules.

Giving somebody access to the Project does not necessarily guarantee access to every underlying resource it references.

For example:

Project shared with Collaborator
        ↓
Source A → accessible
Source B → accessible
Source C → collaborator has no access

The Project may therefore contain a resource that the collaborator cannot fully use.

When a collaborator cannot open or work with part of a Project, check the underlying resource access before assuming the Project share itself is broken.

Sharing the container does not automatically rewrite every dependency's permissions

This is a useful general principle:

Access to Project
≠ automatically owning every Source it references

and:

Access to Map
≠ permission to edit its underlying Project

Geobble maintains resource boundaries rather than flattening every dependency into one global permission.

Before making something public

Check:

The resource is genuinely intended for a broad audience.
Sensitive information has been removed.
Licence and redistribution terms permit publication.
Metadata and limitations are adequate.
Sources inside a Collection are suitable for inherited public access.
A public Map does not expose unintended fields or locations.

Before sharing

Check:

I selected the correct account or team.
The recipient actually needs access.
Viewer, Editor, or Admin is appropriate.
I am not using Admin when Editor is sufficient.
Underlying resources required by the workflow will also be accessible.
The resource should remain private rather than public.

When collaboration ends

Check:

Active shares are still necessary.
Former collaborators no longer need Editor or Admin access.
Team membership still reflects the intended working group.
Outgoing shares on the Sharing page have been reviewed.
Unnecessary grants have been revoked.

Quick decision guide

Use Public when:

Anyone who finds or receives this publication should be allowed to access it.

Use Private when:

Access should remain restricted.

Use Viewer share when:

This specific person or team needs to inspect the resource.

Use Editor share when:

This specific person or team needs to modify the resource.

Use Admin share when:

This collaborator needs delegated resource administration, including managing shares.

Use an organisation role when:

The access reflects the person's general responsibilities across the organisation rather than one isolated resource.