How to Extract Geographic Features from a Document

Use Extract Features when geographic information exists inside a document rather than an existing GIS dataset. In Studio, describe the features and attributes you want, choose whether the result should contain points, lines, or polygons, attach the document as evidence, and select Generate features.

Geobble then produces candidate geographic records for you to review. Nothing is added to a Source until you approve the results and explicitly save them.

When to use Extract Features

This workflow is useful when your source material contains geographic information but is not already structured as reusable spatial data.

For example, a report might describe:

• clinics and the towns where they operate;

• schools and their locations;

• protected areas;

• road sections;

• project sites;

• water points;

• administrative or service areas;

• facilities together with attributes such as operator, category, capacity, or status.

Instead of manually copying each item into a GIS dataset, you can ask Geobble to identify candidate features from the evidence and then review those candidates before creating a Source.

The workflow is:

Document or other evidence
        ↓
Extraction instruction
        ↓
Candidate features
        ↓
Review evidence and geometry
        ↓
Approve / edit / reject
        ↓
Save approved results
        ↓
Geobble Source

Extraction is deliberately review-first. The generated candidates are proposals, not automatically accepted geographic facts.

1. Open Extract Features

Open Studio, then choose Extract Features from the Data tools.

The preparation screen contains the main inputs for the workflow:

• an Instruction;

• a Geometry choice;

• optional Reference sources;

• Evidence;

• the Generate features action.

2. Describe what you want to extract

In Instruction, explain which geographic entities Geobble should identify and which useful attributes should accompany them.

For example:

Extract each named clinic as a point with its name and operator.

A more detailed instruction might be:

Extract each health facility mentioned in the report as a point. Include the facility name, facility type, operator, administrative area, and any explicitly stated capacity.

Try to describe the records you want the resulting dataset to contain, rather than simply asking Geobble to “extract the document”.

Compare:

Extract locations.

with:

Extract each named school as a point with its name, locality, management type, and enrolment when explicitly stated in the report.

The second instruction gives the extraction workflow much clearer boundaries.

Ask for information the evidence can support

The requested attributes should have a reasonable relationship to the evidence you provide.

If a report contains only:

Mbalmayo District Hospital is located in Mbalmayo.

asking for:

name
location

is reasonable.

Asking the extraction process to populate:

annual patient count
number of doctors
construction year
operating budget

would require additional evidence if those values are not present.

Extraction should structure evidence, not quietly turn missing information into asserted facts.

3. Choose the geometry family

Select the kind of geometry the resulting features should have:

• Points

• Lines

• Polygons

Choose this based on what each extracted record is supposed to represent.

Use Points for discrete locations

Examples:

• clinics;

• schools;

• offices;

• wells;

• warehouses;

• stations.

Use Lines for linear features

Examples:

• roads;

• railway sections;

• pipelines;

• river segments.

Use Polygons for areas

Examples:

• protected areas;

• project zones;

• administrative units;

• concessions;

• service areas described by known boundaries.

One extraction session currently targets one geometry family.

If a document contains both facilities and roads and you need them as separate spatial datasets, it is usually clearer to run separate extraction workflows.

Geometry needs more than a place name

Finding the name of a feature in a document and constructing its geometry are separate problems.

For points, a place name may sometimes be resolved to a geographic location.

For lines and polygons, a name alone is generally insufficient to reconstruct the actual geometry.

For example:

Campo Ma'an National Park

identifies a geographic entity, but its name is not itself the polygon boundary.

Similarly:

Yaoundé–Douala road

does not specify the exact line geometry merely by naming the route.

That is where reference Sources can become important.

4. Add reference Sources when useful

Extract Features can use existing Sources as optional reference data.

Reference Sources can help match an entity mentioned in the evidence with geography that is already available in Geobble.

For example, suppose a report lists:

Waza National Park

and an existing Source already contains the polygon for Waza National Park.

That reference data can help the extraction workflow connect the textual mention to an existing geographic feature rather than attempting to infer a boundary from text alone.

Reference Sources are particularly useful for:

• known administrative areas;

• named facilities;

• roads or other known networks;

• protected areas;

• geographic entities for which authoritative or suitable geometry already exists.

Do not add unrelated Sources simply because they are available. Reference data should help resolve the entities you are extracting.

5. Add the document as evidence

Under Evidence, select Files or drag the document into the evidence area.

The current evidence composer accepts document files including:

• Evidence format: PDF · Extension: .pdf

• Evidence format: Microsoft Word · Extension: .docx

• Evidence format: Plain text · Extension: .txt

• Evidence format: Markdown · Extension: .md, .markdown

• Evidence format: HTML · Extension: .html, .htm

• Evidence format: CSV · Extension: .csv

Multiple evidence items can be added to the same workflow.

The evidence system also supports pasted text and HTTP/HTTPS URLs, but this article focuses on document extraction.

After adding the file, it appears in the evidence list before the extraction run begins.

You can use more than one piece of evidence

An extraction does not have to depend on a single document.

For example:

Annual health report.pdf
Facility directory.docx
Official ministry webpage
Pasted clarification notes

could potentially be supplied as evidence for one clearly scoped extraction task.

However, adding more evidence is not automatically better.

If the sources describe different time periods, geographic scopes, or definitions, make those differences explicit in your instruction and review the resulting candidates carefully.

6. Generate candidate features

Once you have:

• written an instruction;

• selected a geometry family;

• added at least one evidence item;

select Generate features.

Geobble creates the extraction workflow, adds the supplied evidence, and begins processing it.

The result is a set of candidate features.

These candidates are not yet committed to a Source.

The interface explicitly keeps the workflow in a review stage before saving.

7. Review the candidate list and map

When extraction finishes, Geobble presents the candidates for review.

For extracted features, the review interface includes information such as:

• the feature name or mention;

• extracted attributes;

• geographic resolution status;

• associated evidence;

• review state.

Candidate geometry is also shown spatially where available.

Do not approve candidates simply because they appear on the map.

Review the candidate itself and the evidence behind it.

8. Open the supporting evidence

Candidates retain references to the evidence used during extraction.

Use View evidence to inspect the relevant source material.

Ask:

• Does the document actually identify this feature?

• Is the extracted name correct?

• Does the evidence support the proposed attributes?

• Is the candidate referring to the right place?

• Is the evidence current enough for the intended use?

This review step is one of the main reasons to use Extract Features rather than treating model output as a finished dataset.

The aim is not merely:

Can the system extract something?

It is:

Can I review why this record is being proposed before I save it?

9. Check geographic resolution

Each candidate has a Resolution state.

A candidate should only be approved as an extracted geographic feature when its geometry has been resolved sufficiently for the workflow.

For point features, a textual place mention may sometimes correspond to multiple possible geographic matches.

For example:

Bafang

might need disambiguation if several geographic candidates are possible.

When alternatives are available, the review interface can allow you to choose the correct match.

Do not pick an alternative solely because its name looks similar. Use the document's geographic context to decide which location is intended.

Lines and polygons require particular care

The current geocoder can help produce point locations, but it does not manufacture unresolved line or polygon geometry from a place name.

If a line or polygon candidate cannot be resolved, the interface advises you to either:

• reject it; or

• rerun the extraction with suitable matching reference data.

That is an important safeguard.

A report mentioning a forest reserve does not contain its polygon boundary merely because it contains the reserve's name.

Use suitable reference geometry when accurate shape matters.

10. Review and edit extracted attributes

Candidate attributes are editable during review.

If Geobble extracted:

name: Central District Hospital
operator: Ministry of Public Health
type: Hospital

compare those values with the evidence.

If an attribute is wrong but the candidate itself is valid, correct the value rather than automatically rejecting the entire feature.

Editing is appropriate when you can determine the correct value from the evidence.

Do not “correct” a field by inserting information you merely assume to be true.

If the evidence is insufficient, either leave the information appropriately unresolved or reject the candidate depending on the intended dataset.

11. Approve or reject each candidate

For each proposed feature you can:

• Approve it;

• Reject it;

• edit it and retain it as a reviewed result.

A candidate that has not been geographically resolved cannot be approved as if its location were settled.

The review interface also provides filters for:

• All;

• Needs attention;

• Pending;

• Approved;

• Rejected.

For larger extractions, these filters help you work systematically through the results.

Bulk controls can approve eligible pending candidates or reject pending results, but use them carefully.

A large candidate count is not a reason to skip validation.

“Approve eligible” is not the same as “all candidates are correct”

Eligibility means the result satisfies the workflow conditions needed for approval.

It does not constitute an independent human verification of the underlying fact.

If the dataset matters for analysis, publication, policy, operations, or other consequential work, review the actual evidence and geography to the level appropriate for that use.

12. Continue to Save

Once you have approved the candidates you want to keep, continue to the save step.

Only approved results are included in the save operation.

You then choose between:

• creating a new Source; or

• appending the extracted features to an existing compatible Source.

This means you can use extraction both to construct a new dataset and to add newly reviewed geographic records to an existing one.

13. Save as a new Source

For a new Source, provide:

• Source title;

• Source slug;

• Collection.

For example:

Source title:
Health Facilities Mentioned in the 2025 Regional Report

Slug:
health-facilities-2025-regional-report

Choose a Collection that appropriately describes where this dataset belongs.

Before saving, also review the field mapping.

14. Review the field mapping

The extracted fields need to become properties in the resulting Source.

Geobble shows the mapping between:

Extracted field
      ↓
Destination field
      ↓
Data type

Supported property types in the current interface include:

• string;

• number;

• boolean;

• date;

• JSON.

For example:

• Extracted field: Facility Name · Destination: facility_name · Type: string

• Extracted field: Beds · Destination: beds · Type: number

• Extracted field: Operational · Destination: operational · Type: boolean

Check that field names and types reflect what the values actually mean.

A field containing "120 beds" should not be treated as a clean numeric field without considering how the extracted value is represented.

Likewise, do not map two unrelated extracted fields onto the same destination merely because their names are similar.

The save interface prevents unresolved mapping conflicts from being silently committed.

15. Or append to an existing Source

Instead of creating a new Source, you can choose Existing source.

The destination needs to be writable and compatible with the extraction's geometry family.

For example, point candidates should not be appended into a polygon Source merely because the attributes look compatible.

When appending, the mapping interface identifies whether extracted fields correspond to existing destination fields or require new ones.

Review that mapping before saving.

Appending changes an existing data resource, so be especially careful about:

• geometry compatibility;

• duplicate records;

• attribute naming;

• field types;

• whether the extracted records genuinely belong in that Source.

16. Save the approved results

Once the destination and mapping are correct, select the save action.

For a new extraction Source this is Create source.

For an existing destination it is Append features.

Only now does the reviewed extraction become durable geographic data.

That boundary is important:

AI-generated candidate
        ≠
saved Source feature

The workflow intentionally separates generation from acceptance.

Extraction is not a guarantee of ground truth

Even a successfully saved extraction should be treated according to the quality of the evidence behind it.

A document can itself contain:

• outdated information;

• ambiguous names;

• incomplete location descriptions;

• transcription errors;

• approximate boundaries;

• conflicting facts.

Geobble can make those statements easier to structure and review, but it cannot make the underlying evidence more authoritative than it is.

Record relevant provenance and limitations with the resulting Source.

Example workflow

Suppose you have a PDF containing:

The programme operates clinics in Buea, Limbe and Tiko. The Buea and Limbe clinics are operated directly by the organisation, while the Tiko clinic is operated by a local partner.

You might configure:

Instruction

Extract each clinic as a point. Include its locality and operator type.

Geometry

Points

Evidence

programme-report.pdf

Possible candidates:

• Feature: Buea clinic · Locality: Buea · Operator type: Direct

• Feature: Limbe clinic · Locality: Limbe · Operator type: Direct

• Feature: Tiko clinic · Locality: Tiko · Operator type: Local partner

You would then:

1. inspect the relevant evidence for each candidate;

2. verify that each place has been resolved correctly;

3. correct any extracted attributes;

4. reject unsupported candidates;

5. approve the valid records;

6. review the destination field mapping;

7. create the Source.

That sequence is what turns extracted information into reviewable geographic data.

Good extraction instructions

A useful instruction usually specifies:

The entity

each clinic

The geometry

as a point

The attributes

name, operator and facility type

Any important constraint

only when explicitly mentioned in the attached report

For example:

Extract each named health facility as a point. Include its facility name, facility type, operator and administrative area when explicitly stated in the evidence. Do not create a facility from general references to a town or district.

That is much clearer than:

Map the health report.

Quick checklist

Before generation:

• I know what one output feature should represent.

• I selected the correct geometry family.

• My instruction names the attributes I actually need.

• I attached the relevant document.

• I added reference Sources where geographic matching requires them.

During review:

• I checked the supporting evidence.

• The candidate represents the intended entity.

• Its geometry is correctly resolved.

• Its attributes are supported by the evidence.

• I corrected or rejected uncertain results rather than approving them automatically.

Before saving:

• Only intended candidates are approved.

• I chose the correct new or existing Source.

• Geometry types are compatible.

• Destination field names are sensible.

• Field types are correct.

• The resulting Source will retain appropriate provenance and limitations.