How to Enrich an Existing Source

Use Enrich Source when you already have the geographic features you need but want to add or update attributes using supporting evidence.

Choose the Source, describe the information you want to add, provide documents, URLs, or pasted text as evidence, then select Find updates. Geobble proposes evidence-backed values for individual features and fields.

Your Source is not changed automatically. You review the proposed values first, approve, edit, or reject them, and then explicitly choose whether to update the original Source or create an enriched copy.

When to use Enrich Source

Enrichment is useful when the geometry already exists and the missing information is primarily descriptive or tabular.

For example, suppose you already have a Source containing health facilities:

name: District Hospital A · geometry: Point · operator: — · capacity: —
name: Clinic B · geometry: Point · operator: — · capacity: —
name: Health Centre C · geometry: Point · operator: — · capacity: —

You also have an official report describing the operator and capacity of those facilities.

Instead of creating a second set of facility geometries, you can enrich the existing features:

Existing Source
    ↓
Existing geographic features
    +
Documents / URLs / text
    ↓
Proposed attribute values
    ↓
Review
    ↓
Approved changes

Enrichment is therefore different from Extract Features.

Extract Features asks:

Which geographic features can be created from this evidence?

Enrich Source asks:

What evidence-backed information can be added to these features that already exist?

If you need to create new geographic records rather than add information to existing ones, see How to Extract Geographic Features from a Document.

1. Open Enrich Source

Open Studio, then choose Enrich Source from the Data tools.

You can also enter the enrichment workflow from a writable Source where the Enrich this source action is available.

The preparation screen asks you for:

an Instruction;
the Source to enrich;
Evidence;
enrichment settings;
the Find updates action.

2. Choose the Source

Select the Source whose existing features should receive additional information.

The enrichment workflow is designed around an existing Source rather than around creating new geometry.

For example, you might choose:

Cameroon Health Facilities

where each row already represents one known facility.

The Source should contain identifiable features that can reasonably be matched with the information in your evidence.

A Source containing:

facility_name
district
geom

is usually easier to enrich from a facility report than one containing anonymous rows with no useful identifiers.

Use a Source you are allowed to work with

The Source picker is oriented towards Sources that can participate in the requested workflow.

Whether you eventually update the original or create a separate enriched copy is decided later.

If the original Source should remain unchanged, you can preserve it by choosing Enriched copy during the save step.

3. Describe the information you want

In Instruction, tell Geobble what properties to find and how they should relate to the existing features.

For example:

Add the official operator and opening date from the attached report.

Or:

For each health facility, find its facility type, operator and bed capacity from the supplied evidence. Only propose values that are explicitly supported.

A useful enrichment instruction normally specifies:

which attributes you want;
which features they apply to;
any evidence-quality requirement;
whether uncertain information should be left unresolved.

For example:

For each protected area in the Source, find the management authority and designation year from the attached official report. Do not infer a designation year when the document does not state one.

That is better than:

Improve this dataset.

Do not ask enrichment to invent missing facts

Enrichment works from supplied evidence.

If your Source contains:

name
geometry

and your evidence contains:

operator
facility_type

those are reasonable enrichment targets.

If the evidence says nothing about:

annual_budget
patient_count
number_of_staff

the workflow should not be treated as a way to manufacture those values.

The objective is to turn evidence into reviewable proposed updates, not to fill every blank cell at any cost.

4. Decide how existing values should be treated

The current enrichment workflow includes an Existing values setting.

There are two modes:

Fill empty values only

Use Fill empty values only when existing populated fields should be preserved.

Conceptually:

Current value: empty · Evidence proposes: Ministry of Health · Result candidate: proposed
Current value: Ministry of Health · Evidence proposes: Private · Result candidate: existing value retained

This is the safer default when the objective is to complete missing information.

It reduces the risk of replacing reviewed values merely because newer evidence contains a different statement.

Allow proposed updates

Use Allow proposed updates when the evidence is also allowed to propose replacements for fields that already contain values.

For example:

Current: Municipal Council · Evidence: Ministry of Health · Proposed: Ministry of Health

This mode is useful when you are deliberately refreshing or correcting a dataset.

It also deserves more careful review because the workflow may propose changing information that is already present.

Do not enable overwriting simply to produce more suggestions.

Ask first:

Is replacing existing values actually part of this enrichment task?

5. Add evidence

Under Evidence, provide the material from which the requested values should be derived.

The current evidence interface supports:

uploaded documents;
URLs;
pasted text.

Supported document types include:

PDF;
DOCX;
TXT;
Markdown;
HTML;
CSV.

You can drag files into the evidence area or choose Files.

You can also paste an HTTP or HTTPS URL, or paste relevant text directly.

Use evidence that can identify the same features

A document may contain useful attributes and still be poor enrichment evidence if there is no reliable way to determine which Source feature each statement belongs to.

For example, suppose your Source contains:

Central Hospital
Central Clinic
Central Health Centre

while the document repeatedly refers only to:

Central facility

That ambiguity matters.

Good matching information might include:

a stable facility name;
an identifier;
locality;
administrative area;
code;
other attributes that distinguish one feature from another.

When identity is ambiguous, review the proposed matches rather than assuming the system has selected the intended feature.

You can combine evidence

A workflow can use several evidence items.

For example:

2026 facility registry.pdf
official ministry webpage
programme report.docx

This can be useful when different sources support different properties.

However, multiple sources can also disagree.

If one report says:

Operator: Ministry of Health

and another says:

Operator: Regional Council

do not approve one merely because it was proposed first.

Check the dates, provenance and context of the evidence.

6. Start the enrichment

When you have:

selected a Source;
written an instruction;
added evidence;

select Find updates.

Geobble creates the enrichment workflow and processes the evidence against the existing Source.

The important sequence is:

Existing Source
      +
Evidence
      ↓
Find updates
      ↓
Proposed values
      ↓
Human review

At this stage, the original Source has not yet been modified.

7. Review the proposed values

When processing finishes, the review interface presents proposed changes at the feature-and-field level.

For enrichment, the table distinguishes:

Feature
Field
Current
Proposed
Review

For example:

Feature: District Hospital A · Field: operator · Current: — · Proposed: Ministry of Health
Feature: District Hospital A · Field: beds · Current: — · Proposed: 120
Feature: Clinic B · Field: operator · Current: Local Council · Proposed: Private Operator

This structure lets you review changes more precisely than accepting an entire enriched dataset at once.

8. Compare Current and Proposed

For every proposed change, ask:

Does this value belong to the correct feature?
Does the evidence actually support it?
Is the field interpretation correct?
Is the proposed value more appropriate than the current one?
Does the value refer to the same time period?
Is the evidence authoritative enough for the intended use?

This is especially important when Allow proposed updates is enabled.

For example:

Current:
Public

Proposed:
Private

could represent:

a genuine management change;
an outdated document;
a feature-matching error;
different definitions of “operator”;
an extraction mistake.

The presence of a proposal alone does not tell you which explanation is correct.

9. Inspect the evidence

Each proposed enrichment value retains evidence information that you can inspect.

Use the Evidence action for a proposed value to review the supporting material.

This allows you to move from:

Geobble proposes “Ministry of Health”.

to:

The supplied report explicitly identifies this facility as operated by the Ministry of Health.

That evidence trail is central to the workflow.

For important data, do not approve values solely from the proposed-value column without checking why they were proposed.

10. Edit a proposed value when appropriate

The proposed value can be edited during review.

For example, Geobble might propose:

Ministry Health

while the document clearly states:

Ministry of Public Health

If the intended value is unambiguous from the evidence, correct the proposal before approval.

Editing should represent a review correction supported by the available information.

It should not become an opportunity to add unrelated facts that were never part of the evidence workflow.

11. Approve or reject proposals

Each proposed value can be reviewed independently.

You can:

Approve the proposal;
Reject it;
edit it and retain the corrected value.

This is useful because an enrichment run can be partly correct.

For example:

Facility A operator      → correct
Facility A capacity      → unsupported
Facility B operator      → correct
Facility B opening date  → ambiguous

You do not need to choose between accepting or discarding the entire run.

Approve the supported cells and reject the unsupported ones.

You can approve values feature by feature

The review interface can also help approve eligible changes associated with one feature.

This may be convenient when several proposed fields for the same feature are clearly supported by the same evidence.

Bulk review controls also exist for eligible pending results.

Use those controls when you have genuinely reviewed the affected proposals—not simply because there are many rows.

12. Filter the review queue

For larger enrichment jobs, use the available review filters:

All
Needs attention
Pending
Approved
Rejected

A useful review sequence is:

Needs attention
      ↓
Pending
      ↓
Approved
      ↓
Final check

This makes unresolved or questionable proposals easier to address before saving.

13. Continue to the save step

Once the proposals you want to keep are approved, continue to Save.

The current enrichment workflow offers two destination modes:

Enriched copy
Update original

This is an important decision.

14. Create an enriched copy

Choose Enriched copy when you want to preserve the original Source and create a new Source containing the approved enrichment.

This is often a good choice when:

the original Source is authoritative;
the enrichment is experimental;
you want to compare before and after;
the added information comes from a different provenance;
you do not want existing workflows to immediately receive the changes.

For the new Source, provide:

Source title;
Source slug;
Collection.

For example:

Original:
Cameroon Health Facilities

Enriched copy:
Cameroon Health Facilities — Operator and Capacity

An enriched copy gives you a clear separation between the original data and the evidence-derived version.

15. Or update the original Source

Choose Update original when the reviewed enrichment should become part of the existing Source.

Use this option deliberately because it changes the working Source rather than creating a separate derivative.

This can make sense when:

you own or manage the Source;
the enrichment is part of routine dataset maintenance;
the approved values should become the current Source state.

Before committing, check all approved proposals and their destination fields.

Updating the original can affect downstream work

The current save interface explicitly warns about downstream behaviour.

When an existing Source is updated:

live Projects that reference the Source remain linked and receive the refreshed artefact;
published Maps remain pinned to their current Source version.

That distinction is useful.

A Source update can therefore flow into ongoing work without silently rewriting an already published map's pinned data version.

Still, treat updates to a widely reused Source carefully. Correct data changes can have analytical consequences for downstream Projects.

16. Review field mapping

Before saving, Geobble shows how proposed properties map into Source fields.

The mapping contains:

the extracted/proposed field;
the destination field;
its data type.

Supported field types in the current workflow include:

string;
number;
boolean;
date;
JSON.

For example:

Proposed field: Operator · Destination: operator · Type: string
Proposed field: Bed Capacity · Destination: bed_capacity · Type: number
Proposed field: Operational · Destination: operational · Type: boolean
Proposed field: Opening Date · Destination: opening_date · Type: date

Check the mapping carefully.

Field names should describe consistent concepts, and field types should match the actual values.

Existing compatible fields can be reused

When saving into an existing Source, Geobble can reuse compatible existing fields.

If an appropriate destination field does not yet exist, a new field can be created as part of the save workflow.

For example:

Proposed:
operator

Existing Source already has:
operator

can reuse the existing compatible field.

But:

Proposed:
operator

Existing field:
ownership_status

should not automatically be treated as equivalent unless those concepts truly mean the same thing.

A field-mapping conflict must be resolved before the save can proceed.

17. Save the approved enrichment

Once:

the review is complete;
destination mode is correct;
field mapping is valid;

save the enrichment.

For a copy, the action creates the enriched copy.

For the existing Source, it updates the original.

Only reviewed and approved results are intended to become committed changes.

The separation remains:

Evidence
   ↓
Proposed value
   ↓
Reviewed value
   ↓
Approved value
   ↓
Saved Source change

That review boundary is one of the most important parts of the workflow.

Enrichment does not change geometry by default

The purpose of this workflow is to enrich existing features with evidence-backed property values.

It is not the primary workflow for creating a new set of geometries.

If your evidence identifies a geographic feature that does not exist in the Source, consider whether it belongs in an Extract Features workflow instead.

For example:

Existing Source:
10 hospitals

Report:
describes attributes for those 10 hospitals
→ Enrich Source

versus:

Existing Source:
10 hospitals

Report:
identifies 4 additional hospitals not in the Source
→ Extract Features may be appropriate for those new records

Do not force genuinely new entities into attribute enrichment merely because you already have a related Source.

Example: enriching protected areas

Suppose your Source contains:

name: Reserve A · geom: Polygon · manager: — · designation_year: —
name: Reserve B · geom: Polygon · manager: — · designation_year: —

You have an official conservation report.

Your instruction could be:

For each protected area in the Source, add the management authority and designation year when explicitly stated in the attached report.

After processing, Geobble might propose:

Feature: Reserve A · Field: manager · Proposed: Ministry of Forestry
Feature: Reserve A · Field: designation_year · Proposed: 2008
Feature: Reserve B · Field: manager · Proposed: Regional Authority
Feature: Reserve B · Field: designation_year · Proposed: 2011

You would then inspect the evidence for each value, reject any ambiguous matches, correct any transcription issues, and approve the supported proposals.

If this is a research derivative, you might choose Enriched copy.

If the Source is your maintained organisational dataset and the evidence is authoritative, Update original may be more appropriate.

Use provenance deliberately

An enrichment adds information from evidence to an existing geographic dataset.

That makes provenance particularly important because the resulting Source may combine:

Geometry provenance
        +
Original attribute provenance
        +
Enrichment evidence

Those may not all come from the same source.

For example, facility geometry might originate from an open-data portal while operator information comes from a ministry report.

Avoid presenting the resulting Source as though every field came from one original dataset.

Where relevant, document:

which evidence supported the enrichment;
the evidence date;
when enrichment was performed;
known limitations;
whether the Source is an enriched derivative.

Be careful with time-sensitive properties

Some attributes change.

Examples include:

facility operator;
operational status;
population;
road condition;
service availability;
administrative responsibility.

If the current Source value and evidence disagree, check their reference dates.

For example:

Current Source:
operator = Organisation A
reference date = 2024

Evidence:
operator = Organisation B
reference date = 2026

may represent a legitimate update.

But reversing those dates could indicate that the evidence is older than the value you are about to overwrite.

Do not interpret “found in a document” as “newer and therefore correct”.

When to prefer an enriched copy

A copy is particularly useful when:

you are testing an enrichment method;
the original Source should remain pristine;
the evidence has uncertain quality;
different teams may want different enriched variants;
the added fields represent a particular research interpretation.

For example:

Original:
National Settlements

Derived:
National Settlements + 2026 Accessibility Classification

can be clearer than modifying the original Source to contain fields that only make sense for one specific analysis.

When updating the original is reasonable

Updating the original makes more sense when:

the Source is explicitly maintained by your team;
the enrichment is an expected maintenance operation;
the new values replace missing or obsolete values;
provenance has been reviewed;
downstream users should receive the updated Source.

The correct choice is about data governance, not convenience.

Quick checklist

Before enrichment:

The geographic features already exist in the Source.
I selected the correct Source.
My instruction identifies the attributes I need.
The evidence can reasonably match those attributes to the Source features.
I chose whether existing populated values may be reconsidered.

During review:

I compared Current and Proposed values.
I inspected supporting evidence where necessary.
The proposal belongs to the correct feature.
The evidence actually supports the value.
I corrected clear extraction errors.
I rejected unsupported or ambiguous proposals.

Before saving:

Only intended changes are approved.
I chose between Enriched copy and Update original deliberately.
Destination field names are correct.
Field types are appropriate.
I considered the effect on downstream Projects.
Relevant provenance and limitations will remain understandable.