How to Publish an Interactive Map

Publishing a Geobble map is a two-stage process.

First, save the current Project as a Map. Geobble creates a Map snapshot with its own title, description, slug, context, current map state, and Source-version references.

The new Map starts private.

After reviewing the Map, open its settings and change Visibility to Public when you are ready to make it available to an audience.

Conceptually:

Project
   ↓
review map and data
   ↓
Save as Map
   ↓
Private Map snapshot
   ↓
review metadata and presentation
   ↓
Visibility: Public
   ↓
Published interactive Map

Before you publish

Do not treat publication as the final button in a styling workflow.

Before creating the Map, review:

• the geographic result;

• the Sources and Project results being used;

• analytical assumptions;

• layer order;

• styles;

• labels;

• legend;

• popups;

• visibility and zoom behaviour;

• the initial map view;

• metadata;

• provenance;

• licences and attribution;

• known limitations;

• whether any information should not be made public.

A visually polished map can still be unsuitable for publication if its data or interpretation is wrong.

1. Finish the Project or Studio review

Start from the Project containing the map you want to publish.

If direct cartographic work is still needed, continue it in Studio first.

For example, you may want to check:

Analysis
    ↓
Layer organisation
    ↓
Styling
    ↓
Labels
    ↓
Legend
    ↓
Popups
    ↓
Initial view
    ↓
Publication review

See How to Continue Project Work in Studio if the map still needs direct GIS or presentation work.

2. Open the Project actions

In the Project, open the actions panel.

Choose:

Save as Map

This creates a Map from the current Project state.

Saving as a Map creates a snapshot

The Map is not simply another URL pointing at the live Project editor.

Geobble creates a Map snapshot from the current Project.

That snapshot includes the map specification and its publication context.

This distinction is important:

Project
→ ongoing working environment

Map
→ saved presentation snapshot

You can continue working on the Project after saving a Map without assuming that every subsequent Project change automatically rewrites the saved Map.

3. Enter the Map title

In Title, give the Map a name that makes sense to its audience.

For example:

Hospital Accessibility in Centre Region

is stronger than:

Final map

A public Map may appear outside the Project where it was created, so its title should make sense independently.

The title is required.

The current Save as Map dialog allows up to 128 characters.

4. Add a description

The Description is optional but strongly recommended for Maps that may become public.

Use it to summarise:

• the subject;

• geographic coverage;

• time period where relevant;

• intended use.

For example:

Interactive map of estimated hospital accessibility across Centre Region, showing settlements by travel-time category using the road and facility data available for the analysis.

A description should help someone decide whether the Map is relevant before they begin interacting with it.

The current description field allows up to 500 characters.

Do not put an entire methodology into the short description. Longer explanation can be added later through the Map's About field.

5. Choose the Map slug

The slug becomes the stable identifier in the Map URL.

For example:

hospital-accessibility-centre-region

Geobble can generate a slug from the title.

The slug accepts lowercase letters, numbers, and hyphens.

Avoid temporary identifiers such as:

final-map-2
test-public
version-new

for Maps intended to be shared.

Unlike the title, the current Map editing interface does not allow the slug to be changed afterwards.

Treat it as a durable identifier.

6. Check the map view before saving

The current Save as Map workflow carries the Project's current viewport into the saved Map.

That includes the current:

• centre;

• zoom;

• bearing where applicable;

• pitch where applicable.

This means the map view you have at the moment of saving matters.

Before selecting Save as Map, position the map so that the initial view represents the intended geographic subject.

For example, a Cameroon-wide Map should not accidentally open zoomed into one street because that happened to be your last editing position.

7. Save the Map

Select:

Save as Map

Geobble creates the Map and then opens its Map page.

At this stage, the Map should still be treated as a draft publication object.

It has been saved as a Map, but that does not mean you must immediately expose it publicly.

The Map starts private

The current Save as Map flow creates the new Map as a private Map.

This is intentional from a workflow perspective because it gives you an opportunity to review the publication object before exposing it to the public.

Think of:

Save as Map

as:

Create the durable Map I may publish.

and:

Visibility: Public

as:

Make this Map publicly accessible.

Keeping those actions separate reduces the chance of unintentionally publishing unfinished work.

8. Review the saved Map

Open the newly created Map and inspect it as a Map rather than as an editor.

Check:

• the initial geographic view;

• all visible layers;

• layer loading;

• legend;

• labels;

• popups;

• interactive behaviour;

• title;

• description;

• attribution and explanatory material.

Try to view it from the perspective of someone who did not participate in the Project.

Ask:

Would this person understand what the Map shows and how to interpret it?

Check interactive behaviour

An interactive Map can fail communicatively even when its static appearance is good.

Test relevant actions such as:

• clicking features;

• opening popups;

• zooming;

• changing scale;

• searching if configured;

• any supported map interactions.

Also check whether content remains understandable on both a large screen and a smaller viewport where relevant.

Do not assume that interaction configuration that worked during editing necessarily communicates clearly to an external viewer.

9. Open the Map settings

When you are ready to manage publication metadata and visibility, open the Map's edit/settings interface.

The current Map settings allow you to modify:

• title;

• description;

• About content;

• visibility;

• embed availability.

The slug is displayed but cannot be edited.

10. Add or refine the description

The short description should answer:

What is this Map?

For a public Map, prefer useful context over promotional wording.

For example:

District-level comparison of travel-time accessibility to hospitals in Centre Region using the Sources documented in the associated analysis.

That is more useful than:

An amazing interactive healthcare map.

Public metadata should help viewers understand the content and its limits.

11. Use the About field for fuller context

The Map settings include an About field for longer explanatory content.

Use it when the audience needs more context than fits naturally in the short description.

For example, the About content might explain:

• what the Map measures;

• the main data Sources;

• reference dates;

• methodology;

• important assumptions;

• attribution;

• known limitations;

• how the result should and should not be interpreted.

The current About renderer supports ordinary explanatory content such as:

• paragraphs;

• links;

• bold;

• italic;

• lists;

• level-three and level-four headings.

Do not rely on unsupported complex formatting when preparing this content.

Explain important limitations

If a Map could reasonably be misinterpreted, put the limitation where viewers can encounter it.

For example:

Travel-time estimates are modelled from the road-network data available for this analysis and should not be interpreted as observed journey times.

or:

Facility status reflects the reference date documented in the underlying Source and may not represent current operational status.

A limitation hidden only in the original Project conversation is not useful to a public viewer.

12. Change Visibility to Public

When the Map is ready, change Visibility from:

Private

to:

Public

and save the changes.

A public Map can be accessed according to Geobble's public Map access model.

This is the actual audience-facing publication step.

Do not change visibility simply because the Map has been saved successfully.

Publication should follow review.

Private and Public answer different questions

Private asks:

Should this Map remain restricted to authorised access?

Public asks:

Is this Map intended to be openly accessible?

Neither setting says anything about whether the Map is analytically correct.

A private Map can be completely finished.

A public Map can still be wrong if it was not reviewed.

Visibility is an access decision, not a quality score.

13. Enable embedding only when needed

The current Map settings also include Embed behaviour.

Embedding can only be enabled for a public Map.

Use it when you want the interactive Map to be displayed within another website or supported surface.

For example:

organisation website
      ↓
embedded Geobble Map

Do not enable embedding automatically for every public Map.

Ask whether third-party embedding is actually part of the publication plan.

If the Map should only be visited through its Geobble page, embedding may be unnecessary.

Public visibility is required for embeds

The current interface disables the embed control while the Map is private.

Conceptually:

PRIVATE
→ Embed unavailable

PUBLIC
→ Embed can be enabled

Making a Map private again should therefore be treated as changing its public delivery expectations as well.

What happens to Source data when a Map is saved?

Published Maps record the versions of the Sources used by the saved map specification.

This is important because a working Project can continue to reference live resources, while the Map needs a stable publication view.

The saved Map therefore carries Source-version pins associated with its snapshot.

Conceptually:

Project
→ Source A: current working version
→ Source B: current working version

Save as Map
        ↓
Map snapshot
→ Source A version pinned
→ Source B version pinned

This helps the Map remain tied to the data state with which it was published rather than silently changing every time an upstream Source is updated.

Updating a Source does not silently rewrite an existing published Map

This is especially important when Sources are enriched or otherwise updated later.

For example:

Published Map
→ Health Facilities, version at publication

Later:
Health Facilities Source updated

The existing published Map remains pinned to its publication Source version rather than automatically switching to the changed Source.

This protects publication stability.

It also means:

Updating a Source is not the same as republishing a Map.

If the published Map should incorporate newer Source data, create or save an appropriate new Map snapshot from the updated work.

Map versions are separate publication snapshots

When Maps are saved from a Project, Geobble assigns version identifiers such as:

v1
v2
v3

for successive Map snapshots associated with that Project.

This does not mean that every minor Project edit automatically produces a new Map version.

A new saved Map snapshot is a deliberate publication action.

For example:

Project
   ↓
Save as Map
   ↓
v1

continue working
   ↓
update analysis
   ↓
review
   ↓
Save as another Map
   ↓
v2

Treat these as publication snapshots rather than ordinary editor autosaves.

A published Map is not the Project

The Map does not expose the full working Project merely because it came from that Project.

The roles remain different:

Project
→ analysis and working environment

Studio
→ direct GIS and cartographic editing

Map
→ audience-facing geographic presentation

This separation lets you keep working material private while publishing the result intended for viewers.

Check Source redistribution rights before publication

A Project can contain resources you are allowed to use without necessarily being allowed to redistribute them in a public Map.

When Geobble creates a Map snapshot, the publication workflow checks whether the Project and its referenced resources are usable for redistribution into that Map.

If those requirements are not satisfied, the Map cannot simply be published by bypassing the underlying access model.

Before publication, make sure the Sources and other resources used in the Map can legitimately support the intended form of sharing.

Public Maps can remain usable even when source-resource access changes

The published Map is designed as a publication snapshot rather than a live editor that rechecks every private Source permission during every viewer interaction.

This is another reason to treat publication deliberately.

If private or shared information is included in a Map snapshot that you then make public, changing the Source's visibility afterwards should not be your primary mechanism for undoing that publication decision.

Review sensitive information before making the Map public.

If a Map itself should no longer be public, change the Map's own access settings.

Review the map for sensitive information

Before changing visibility to Public, inspect whether layers or popups expose:

• personal information;

• confidential locations;

• internal identifiers;

• private organisational fields;

• sensitive infrastructure details;

• fields that were useful during analysis but should not be public.

For example, a facility Source may contain:

facility_name
type
operator
capacity
internal_record_id
contact_phone
internal_notes

A public Map may only need:

facility_name
type
operator
capacity

Use the Project and Studio workflow to remove unnecessary public-facing fields from the presentation.

Publication should expose the intended result, not every attribute available in the underlying data.

Test the map as a viewer

Before announcing or distributing the public URL:

1. open the Map;

2. check the initial view;

3. click representative features;

4. test popups;

5. zoom in and out;

6. check labels;

7. read the legend;

8. read the description and About text;

9. confirm that no private working information appears.

If the intended audience includes mobile users, test a smaller screen as well.

Example publication workflow

Suppose your Project is:

Hospital Accessibility in Centre Region

You finish the analysis and cartographic refinement.

Before saving

Check:

• travel-time assumptions;

• facility data;

• road data;

• analytical layer;

• legend;

• district labels;

• popups;

• initial extent.

Save as Map

Title

Hospital Accessibility in Centre Region

Description

Interactive view of estimated travel-time accessibility to hospitals across Centre Region.

Slug

hospital-accessibility-centre-region

Save the Map.

Review the private Map

Check it outside the Project editing workflow.

Add About content

Explain:

• reference data;

• travel-time methodology;

• relevant assumptions;

• important limitations.

Publish

Change:

Visibility:
PRIVATE

to:

Visibility:
PUBLIC

and save.

The Map is now the publication object intended for viewers.

When to create another Map snapshot

Create a new snapshot when the publication itself materially changes.

Examples:

• new Source data;

• revised analytical method;

• important corrected result;

• major change to the Map's intended interpretation.

Do not create a new public Map merely to fix a typo in the description if the existing Map's settings can be edited directly.

A useful distinction is:

Publication metadata changed
→ edit existing Map

Underlying map/data snapshot changed materially
→ consider a new Map snapshot

Publication checklist

Data and analysis

• The correct Sources are being used.

• Source dates and geographic coverage are appropriate.

• Analytical assumptions have been reviewed.

• Generated results have been checked.

• Important limitations are documented.

Map presentation

• Layer order is correct.

• Styling communicates the intended meaning.

• Labels are readable.

• Legend categories are understandable.

• Popups contain useful viewer-facing fields.

• The initial map extent is appropriate.

• Relevant interactions work.

Metadata

• The title makes sense outside the Project.

• The slug is durable.

• The description explains the Map.

• About content provides enough methodological context where needed.

• Attribution, provenance, and limitations are clear.

Access

• I have reviewed the Map while it is private.

• Referenced resources can support the intended publication.

• No sensitive information is unintentionally exposed.

• Public visibility is intentional.

• Embedding is enabled only if needed.