How to Create a Project

Use a Project when you want to organise geographic work around a question or outcome: comparing places, measuring accessibility, creating buffers, joining datasets, identifying features, or developing a map.

To create one, open Projects, select New Project, enter a title and any useful tags, then create the Project. Geobble opens the new Project so you can begin describing what you want to accomplish and add relevant geographic context.

What a Project is for

A Project is a workspace for mapping, spatial analysis, and agent-assisted geographic work.

It is usually the right starting point when your starting point is something like:

Which communities have the poorest access to health facilities?

or:

Compare these districts by population and service availability.

or:

Create 5 km buffers around these facilities and identify the settlements inside them.

Rather than requiring you to define every GIS operation beforehand, the Project gives you a place to establish the objective, attach relevant Sources and Maps, request work, inspect the results, and refine them.

A typical flow is:

Question or desired result
        ↓
Create Project
        ↓
Add geographic context
        ↓
Describe the task
        ↓
Review the proposed work
        ↓
Refine or continue in Studio

If you already know that you only need direct layer styling or map editing, you may prefer to start in Studio instead. See Getting Started with Geobble for the distinction.

1. Open Projects

From your Geobble account, open Projects.

The Projects page lists the Projects available to the current account, grouped by when they were created.

Select New Project.

2. Enter the Project title

The creation dialog requires a Project title.

Choose a title that describes the work rather than a temporary activity.

For example:

Health Facility Accessibility in Littoral

is more useful than:

New analysis

Likewise:

Compare Flood Exposure Across Douala Districts

provides more context than:

Flood map

A Project may accumulate conversations, Sources, derived results, layers, and later Studio work. A descriptive title makes it much easier to recognise when you return to it.

The current Project creation flow does not require you to enter the full analytical objective in the creation dialog. The title identifies the Project; you describe the actual task once you open it.

3. Add optional tags

You can also add tags while creating the Project.

Tags are optional.

They are useful for organising related work, for example:

health
accessibility
cameroon

or:

environment
forest
monitoring

Use tags as broad organisational labels rather than trying to encode the entire Project description into them.

For example:

health
accessibility
littoral

is preferable to:

project-to-calculate-travel-times-from-all-health-facilities

Geobble normalises tags when the Project is created, so keep them concise and reusable across related Projects.

4. Create the Project

Select Create.

Geobble creates the Project and opens it automatically.

New Projects are private. Creating a Project does not publish the work or make it available in the public catalogue.

Sharing is a separate action that you can perform later when collaboration is required.

The creation step itself is intentionally small:

Title
+
optional tags
        ↓
Create Project

The more important configuration happens through the work you add afterwards.

5. Start with a clear objective

Once the Project opens, describe the result you want.

A good first request usually explains:

• the geographic question;

• the area or features involved;

• the expected comparison or output;

• any important constraints you already know.

For example:

Compare access to hospitals across the districts of Douala using travel time. Help me identify the Sources I need before running the analysis.

or:

Using the facility and settlement Sources in this Project, create 5 km buffers around the facilities and identify settlements outside all buffer areas.

or:

Compare these regions by population density and health-facility coverage, then prepare a map that makes the differences easy to inspect.

The first request does not need to contain every technical parameter.

It should give the Project enough direction to establish what data and analysis are required.

Prefer an objective over a vague instruction

Compare:

Analyse these data.

with:

Compare these districts by access to secondary schools and identify which areas appear least served.

The first request says very little about what a successful result should look like.

The second establishes:

• the units being compared;

• the subject of the analysis;

• the concept being measured;

• the intended output.

That makes subsequent GIS choices easier to evaluate.

You can also begin from a starter action

A new Project can support common starting directions such as:

• finding a public dataset;

• uploading and mapping your data;

• comparing places;

• measuring accessibility;

• creating buffers;

• joining datasets;

• identifying features in an area;

• styling and preparing a map for publication.

These should be treated as starting points, not rigid workflows.

For example, selecting an accessibility-oriented action helps prepare an initial request, but you still need to determine the appropriate destinations, network data, measurement assumptions, and geographic scope before relying on the result.

6. Add the data the Project needs

Many geographic questions cannot be answered from the text of the request alone.

A Project becomes more useful when it has the appropriate Sources and Maps as context.

For example, a Project about healthcare accessibility may need:

Health facilities
+
Settlements or population
+
Road network
+
Study-area boundaries

A Project comparing deforestation and communities might need a very different context.

Do not attach every Source you have.

Add resources because they contribute to the current objective.

The dedicated workflow is covered in How to Add Sources and Maps as Project Context.

Context is not the same as copying all the data

Adding a resource as Project context establishes that it is relevant to the Project.

It allows Project work to reference the geographic resource without requiring you to recreate the dataset solely for that Project.

This means it is useful to think of Project context as:

These are the resources this Project should be able to work with.

rather than:

These are all the files stored inside this Project.

That distinction becomes increasingly important when the same Source is reused across several analyses.

7. Send the first request

Once the objective and useful context are in place, send the request to the Project.

Depending on the task, the Project can help with work such as:

• querying geographic data;

• creating or styling layers;

• running spatial analysis;

• resolving places;

• running mobility or accessibility analysis;

• configuring map interactions;

• managing relevant Project context;

• adjusting the map view.

The available operation depends on what you ask and what data the Project has available.

Do not assume the first generated result is automatically the final answer.

8. Review what the Project proposes or produces

GIS operations contain assumptions.

For example:

Create buffers around these schools.

still raises questions such as:

• What buffer distance?

• In what units?

• Using which CRS?

• Should overlaps remain separate or be dissolved?

Likewise:

Find the nearest hospital.

may mean straight-line distance or network travel distance depending on the purpose.

Review:

• which Sources were used;

• filters;

• joins;

• distances;

• units;

• geographic scope;

• generated layers;

• analytical assumptions.

If something is unclear, ask the Project to explain or refine it before treating the result as authoritative.

Projects support iterative work

You do not need to formulate the entire workflow perfectly in one message.

For example:

Compare access to hospitals across these districts.

may lead to:

Use travel time instead of straight-line distance.

then:

Limit the comparison to hospitals that are operational.

then:

Classify the districts into five groups and make the result easier to compare visually.

This iterative approach is often more useful than trying to encode an entire GIS specification into the first request.

The important requirement is to keep the overall Project objective coherent.

Keep one Project centred on one meaningful objective

A Project can evolve, but avoid turning one Project into a container for unrelated work.

For example:

Project:
Health Facility Accessibility in Littoral

could reasonably include:

• facility coverage;

• road-network analysis;

• population comparisons;

• district-level summaries;

• accessibility maps.

It probably should not also become the place where you analyse:

• national forest loss;

• port infrastructure;

• election results;

simply because those datasets are available.

When the objective changes substantially, creating another Project keeps context and reasoning easier to understand.

Use tags for organisation, not analytical meaning

Project tags can help you find related work, but they do not replace a clear title or objective.

For example:

Title:
Health Facility Accessibility in Littoral

Tags:
health
accessibility
cameroon

is clear.

A Project named:

Analysis

with twenty tags is not.

The Project's purpose should remain understandable even without inspecting every tag.

Projects remain private unless shared

Projects are private resources.

They are different from public catalogue resources such as publicly visible Sources or Maps.

If another person needs access to the Project, use the Project-sharing controls rather than assuming that publication of a related Map gives access to the underlying Project.

Sharing and publishing solve different problems:

Share Project
→ collaborate on the working Project

Publish Map
→ make a finished geographic presentation available to an audience

A later Help article can cover sharing and permissions in more detail.

Continue in Studio when direct editing becomes more useful

A Project is especially useful for objective-driven and agent-assisted work.

At some point, you may want more direct control over the resulting layers or map.

Projects can be opened in Studio for that purpose.

For example, after using a Project to:

• prepare an analysis;

• generate layers;

• organise context;

• develop the initial map;

you may continue in Studio to refine the cartography or work directly with the map.

See How to Continue Project Work in Studio.

Example: creating a healthcare accessibility Project

Suppose your goal is to identify communities with poor access to hospitals.

Create the Project

Title

Hospital Accessibility in Centre Region

Tags

health
accessibility
centre

Define the objective

Your first request might be:

Identify communities in Centre Region with poor access to hospitals. I want to compare travel time rather than straight-line distance. Tell me what additional context is required before we run the analysis.

Add context

You might then add:

• hospital locations;

• settlement or population data;

• an appropriate road network;

• administrative boundaries.

Refine

After reviewing the first result:

Separate results by division and summarise the share of settlements more than 30 minutes from a hospital.

Then:

Create a map layer showing those least-accessible settlements.

At that point the Project has a clear analytical thread rather than a collection of unrelated prompts.

Project creation does not require the data to be ready first

You can create the Project before you have assembled every Source.

This can be useful when part of the work is determining:

What data do I actually need?

For example:

I want to compare flood exposure across Douala. Help me identify the minimum Sources needed for a useful analysis.

You can then find, upload, or prepare those Sources and add them as context.

Conversely, if you already have all the data, you can add it immediately and move directly into the analysis.

Quick checklist

When creating the Project:

• The title clearly identifies the objective or subject.

• Tags are concise and useful rather than excessive.

• I understand that the Project starts private.

After creation:

• I can state the desired geographic result clearly.

• I identified the Sources or Maps that provide necessary context.

• I avoided adding unrelated resources.

• My first request is specific enough to evaluate the result.

• I will review analytical assumptions rather than accepting output solely because it renders correctly.

As the Project develops:

• The work is still centred on the original objective.

• Important inputs and assumptions remain understandable.

• I move into Studio when direct GIS or cartographic refinement is more appropriate.