How to Continue Project Work in Studio
Open a Geobble Project in Studio when you need direct GIS and cartographic control over its layers, styling, labels, filters, interactions, and map presentation.
Explain the current handoff between Project and Studio, including how to open an existing Project in Studio, what is shared between the two editing surfaces, what remains surface-specific, which kinds of work belong in Studio, and how to move between agent-assisted and direct editing without treating Studio as a separate copy.
How to Continue Project Work in Studio
Open a Project in Studio when the work has reached a point where direct GIS or cartographic editing is more useful than continuing entirely through the Project's agent-assisted workspace.
From the Projects list, open the Project menu and choose Open in Studio. Geobble opens the Studio workspace associated with that Project.
This does not clone the Project. Project and Studio are two editing surfaces over the same underlying Project.
When to move from a Project into Studio
Projects are especially useful when the work begins with an objective:
Compare access to hospitals across these districts.
Join these Sources and identify underserved areas.
Create buffers around these facilities.
Help me prepare a map showing the result.
Studio becomes useful when you want direct control over how the geographic work is organised or presented.
For example:
Project
→ define objective
→ add context
→ run or refine analysis
→ create layers
↓
Studio
→ organise layers
→ edit styling
→ configure labels
→ adjust visibility
→ refine legend
→ configure popups
→ prepare final mapYou do not have to choose permanently between the two.
They are complementary working surfaces.
Project and Studio are not separate copies
When you open an existing Project in Studio, Geobble associates that Project with its Studio collaboration workspace.
Opening it again later reuses the same Studio workspace.
Conceptually:
Project
├── Project workspace
│ agent-assisted editing
│
└── Studio workspace
direct GIS editingnot:
Project
↓
clone
↓
unrelated Studio copyThis distinction matters because Studio is intended as another way to work on the Project rather than an export destination.
1. Find the Project
Open Projects in the Geobble account that owns or provides access to the Project.
Locate the Project you want to continue.
The Project must be readable by your current account.
You do not necessarily need edit permission merely to open the Studio representation. If you only have read access, Studio can present the Project in a locked state rather than granting write permissions you do not have.
2. Choose Open in Studio
Open the Project's action menu and select:
Open in Studio
Geobble prepares the Studio workspace associated with the Project and opens it.
The first time the Project is opened in Studio, Geobble may establish the Studio collaboration workspace internally.
On later visits, that existing workspace is reused.
You do not need to create a separate Studio copy manually.
3. Review the Project when Studio opens
Once Studio opens, inspect the current map and layer state before making changes.
Check:
which layers are present;
which Sources they reference;
current layer order;
visible and hidden layers;
current styling;
labels;
filters;
legend configuration;
popup behaviour;
map view and extent.
This is especially useful when the Project has already undergone several rounds of agent-assisted work.
Before changing presentation details, make sure the current geographic result is the one you actually intend to refine.
What Studio is designed to control
Studio is the direct collaborative GIS editor.
It is particularly appropriate for editor-facing work such as:
layer styling;
layer display settings;
legends;
labels;
filters;
visibility;
zoom ranges;
layer grouping;
attributes;
map settings;
map view;
annotations;
direct cartographic refinement.
For example, you might use the Project to request:
Create a layer showing settlements more than 30 minutes from a hospital.
Then use Studio to decide:
where that layer appears in the stack;
how it is styled;
which zoom levels show it;
which labels appear;
how the legend describes it;
which attributes are visible to viewers.
Use the Project for objective-driven reasoning
The Project surface remains useful for work such as:
asking geographic questions;
running spatial analysis;
querying data;
creating new analytical layers;
resolving places;
performing mobility analysis;
managing Project context;
requesting broader map changes through the assistant.
For example:
Recalculate accessibility using 45 minutes instead of 30.
is usually an analytical change.
Whereas:
Make the resulting accessibility layer visually subordinate to the district boundaries.
is primarily a cartographic refinement.
The first naturally fits the Project workflow.
The second naturally fits Studio.
There is overlap
The boundary is not absolute.
Both editing surfaces can influence the map.
The important difference is the interaction model:
Project
Describe objective
↓
Ask for change
↓
Review resulting map/specStudio
Select layer or setting
↓
Edit directly
↓
See the resulting mapChoose the surface that makes the current task easiest to inspect and control.
4. Organise the layer stack
A common first Studio task is reviewing the layer order.
Suppose the Project contains:
Hospital Accessibility
District Boundaries
Population
HospitalsThe layer stack controls which layers appear above others.
For example, placing a large filled polygon above point locations may obscure those points.
Use Studio to arrange layers so that the visual hierarchy reflects the purpose of the map.
A useful order might be:
Hospitals
District Boundaries
Accessibility Areas
Population Basedepending on the intended presentation.
There is no universally correct layer order. It depends on what the viewer needs to see.
5. Refine layer styling
Studio lets you directly adjust how map layers appear.
Depending on the layer and available styling controls, this can include choices such as:
fill styling;
line styling;
point styling;
opacity;
data-driven visual properties;
classification;
colour scales.
Use visual differences to communicate actual differences in the data.
Avoid adding visual complexity merely because more styling controls are available.
For example, if the analytical result is a simple binary distinction:
Within 30 minutes
Beyond 30 minutesa clear two-category treatment may communicate the result better than an unnecessarily elaborate classification.
6. Configure visibility and zoom behaviour
A layer that is useful at one scale may be distracting at another.
Studio supports direct control over layer visibility and zoom ranges.
For example:
National overview
→ show regions
Closer zoom
→ show districts
Local zoom
→ show individual facilitiesThis can make interactive maps substantially easier to read.
If labels or detailed features overwhelm the map when zoomed out, adjust when they become visible rather than trying to make all content readable at every scale.
7. Configure labels
Labels can make a map much easier to understand—or much harder.
Use Studio to review:
which layer needs labels;
which field should provide the label text;
whether labels are useful at the current zoom level;
whether they collide excessively;
whether the hierarchy between different label types is clear.
For example, a map showing health-facility accessibility may need district names at a regional scale while individual facility names only make sense at closer zoom levels.
Do not label every available feature solely because the dataset contains a name field.
8. Review the legend
The legend should explain the visual encodings the viewer actually needs to interpret.
If the map contains:
Travel time
0–15 min
15–30 min
30–45 min
45+ minthe legend should communicate those categories clearly.
If a layer is purely contextual and its meaning is obvious, it may not deserve the same legend emphasis as the analytical result.
Use Studio to ensure that the map's visual hierarchy and legend hierarchy agree.
9. Configure popups and interactive presentation
A geographic feature may contain many fields.
That does not mean every field belongs in a viewer-facing popup.
For example, a hospital Source might contain:
internal_id
source_record_id
facility_name
facility_type
operator
capacity
import_timestampA public-facing popup might only need:
Facility name
Facility type
Operator
CapacityUse Studio to make the interactive presentation fit the audience rather than exposing raw implementation fields unnecessarily.
10. Adjust map settings and view
Studio also owns editor-facing map settings and view configuration.
Before treating the map as finished, inspect:
initial geographic extent;
zoom;
map composition;
background/basemap;
whether important features are visible on first load.
A technically correct map can still be difficult to use if it opens at an irrelevant location or scale.
Project context remains relevant
Opening the Project in Studio does not mean its reusable data relationships cease to matter.
The Project still depends on its Sources, Collections, derived results, and other context.
If an input Source becomes unavailable or access is revoked, moving into Studio does not magically create an archival copy of that Source.
Project resource references generally remain references to the underlying resources.
That means data governance and access still matter after the transition to Studio.
Studio does not copy Project conversation history
Project and Studio share the Project, but they do not share their assistant conversation history.
If you discussed:
Use a 30-minute travel-time threshold because this study follows the programme's accessibility definition.
in the Project conversation, you should not assume the Studio assistant automatically has that conversation available.
Studio has its own conversations.
This is an important distinction:
Shared:
Project and map state
Separate:
Project conversation history
Studio conversation historyWhen an assumption from the Project conversation is important to subsequent Studio work, restate the relevant context rather than assuming the other assistant surface knows it.
Studio also has an assistant
Studio supports its own map-editing assistant.
That means moving into Studio does not necessarily mean abandoning AI-assisted work.
The difference is that the Studio assistant operates within the Studio editing surface and its responsibilities.
You might use direct controls for precise edits and the Studio assistant for broader map-editing requests.
For example:
Make the hospitals more prominent and reduce the visual weight of the administrative boundaries.
can be useful as a Studio map-editing request.
But keep analytical assumptions in mind: a cartographic assistant should not be treated as silently redefining the underlying analysis.
Be careful when changing filters
Filters can change which data appears in a layer.
That may substantially change the meaning of the map.
For example, changing:
facility_status = operationalto no filter at all may cause closed or planned facilities to appear.
That is not merely a cosmetic adjustment.
When editing filters in Studio, understand whether the filter is:
purely presentational;
part of the analytical logic;
necessary to reproduce the intended result.
If the change alters the analytical definition itself, consider whether the Project workflow should also be revisited.
Direct styling does not repair incorrect analysis
Suppose a Project produces a layer in the wrong place because of an input or analytical issue.
Changing:
colour;
opacity;
labels;
layer order;
will not make the geographic result correct.
If Studio reveals that the underlying result itself is wrong, return to the analytical question.
For example:
Incorrect buffer distance
→ fix analysis
Poor buffer colour
→ fix in StudioThis distinction prevents presentation work from masking data problems.
Moving into Studio does not mean the Project is finished
You can return to the Project later.
For example:
Project
→ create initial analysis
Studio
→ inspect and style
Project
→ revise analysis
Studio
→ continue refinementThis can be a normal workflow.
Use whichever surface is better suited to the current change.
Example workflow
Suppose you created a Project called:
Hospital Accessibility in Centre RegionIn the Project you:
add hospitals, settlements, roads, and boundaries;
request travel-time analysis;
create a layer of settlements more than 30 minutes from a hospital;
review the analytical result.
Now open the Project in Studio.
In Studio you might:
move the underserved-settlement layer above contextual layers;
reduce the opacity of background administrative polygons;
choose a clear style for the accessibility result;
add district labels;
show hospital names only at closer zoom levels;
configure useful popup fields;
adjust the initial map extent;
review the legend.
If you then discover that the 30-minute threshold itself should have been 45 minutes, that is an analytical change.
Return to the Project workflow, revise the analysis, and then continue the presentation work in Studio.
Use the two surfaces deliberately
A useful rule is:
Use Project when the question is primarily what geographic work should be done.
Use Studio when the question is primarily how the geographic result should be directly edited or presented.
Examples:
Task: Compare two geographic areas · Usually start in: Project
Task: Calculate accessibility · Usually start in: Project
Task: Create a buffer · Usually start in: Project
Task: Join or query Sources · Usually start in: Project
Task: Rearrange layers · Usually start in: Studio
Task: Refine layer styling · Usually start in: Studio
Task: Configure labels · Usually start in: Studio
Task: Configure legend · Usually start in: Studio
Task: Configure visibility and zoom ranges · Usually start in: Studio
Task: Refine popups · Usually start in: Studio
Task: Adjust the map view · Usually start in: Studio
This is a working guideline rather than a technical prohibition.
Some capabilities overlap, but the distinction helps keep the workflow understandable.
Access permissions are preserved
Opening a readable Project in Studio does not grant additional access.
If you can read but not edit the Project, Studio can remain locked for editing.
This means:
Can read Project
≠
Can modify ProjectThe Studio workspace is collaboration infrastructure associated with the Project, not a mechanism for bypassing Project permissions.
Review before publication
Studio is often where the map becomes presentation-ready, but do not publish solely because styling is complete.
Before publication, check:
underlying data;
analytical assumptions;
visible layers;
labels;
legend;
popups;
geographic extent;
attribution;
metadata;
limitations;
intended audience.
The publication workflow is covered in How to Publish an Interactive Map.
Quick checklist
Before opening Studio:
The Project contains the geographic work I want to refine.
I understand the current analytical result.
I know whether I have edit permission.
When Studio opens:
The expected layers are present.
The map is showing the intended result.
I understand which Sources or derived results the layers use.
During refinement:
Layer order supports the map's message.
Styling reflects the data appropriately.
Labels are useful at the chosen scales.
Visibility and zoom ranges are sensible.
Legend categories are understandable.
Popups expose useful fields rather than raw clutter.
I have not used styling to hide an analytical problem.
Before returning or publishing:
Important analytical assumptions are still valid.
Any major analytical changes are handled in the appropriate workflow.
The final map remains consistent with the Project objective.