How to scope a GeoAI project

A GeoAI project that begins with “let’s apply AI to our satellite data” usually ends in a slide deck. A project that begins with a specific question usually ends in a map that someone uses. The difference is made in the first two weeks, in how the project is scoped.

This guide gives you a seven-step framework that you can run in a workshop with your team and any technical partner. By the end you should have a one-page scope that a data scientist could start from, and that a manager can approve with confidence.

Step 1: write the question as a decision

Start with the action someone will take. “Which fields need irrigation support this month?” is a decision. “Map crop health” is an activity. Decisions force clarity about who the user is, how often they need the answer and how accurate it must be.

• Who will use the result, and what will they do differently?
• How often do they need it: once, monthly, weekly?
• How bad is a wrong answer, and in which direction?

Step 2: set the area and the time window

Define the boundary of the area precisely, with a file if possible, and the period you care about. A model that must work across a whole country, in every season, is a far bigger project than one for two districts during the growing season. Be honest about how much you actually need.

Step 3: find suitable imagery

Check that imagery exists that can answer the question. You need the right resolution, the right frequency and the right bands, and enough clear images after cloud is removed.

• Resolution: can the smallest thing you care about be seen?
• Frequency: are there enough usable images in your window, allowing for cloud?
• Bands: do you need near-infrared, short-wave infrared or radar?
• Cost and licence: free data may be enough, and commercial data may restrict sharing.
• Archive: is there history if you need to compare against past years?

Step 4: plan the labels

Supervised models learn from labelled examples, and labels are usually the slowest, most expensive part of the project. Decide who will create them, from what source and how many are needed.

• Field visits or survey data from local officers.
• Existing maps, which can be a starting point but may be out of date or inconsistent.
• Manual marking on high-resolution images by trained staff.
• A written guide so that everyone labels the same way.

Step 5: choose the success measure first

Pick the measure and a minimum acceptable score before building anything. Otherwise the target quietly moves to wherever the result lands.

• For maps: overall and per-class accuracy, tested on areas the model has never seen.
• For detection: how many real objects were found, and how many false alarms were raised.
• For forecasts: error compared with a simple baseline, such as last year’s value.
• For the business: the time or money saved, or the decision made faster.

Step 6: run a small pilot

Choose a modest area, perhaps one district, and aim to produce a real result in four to eight weeks. Compare the output with ground truth, ask the intended users to try it and note what they would change. The pilot is not a smaller version of the final product. Its purpose is to answer the biggest uncertainty cheaply.

Step 7: decide how results reach users

Plan the delivery from the start. A beautiful model that produces a raster file nobody can open has not helped anyone. Options include a map on a web dashboard, a regular report, an alert by message or email, or an interface other systems can call.

• Who needs to see it, on what device?
• How fresh must it be, and who updates it?
• How will users know how much to trust it, and what should they do when it looks wrong?

A one-page scope template

1. 01The decision and the user.
2. 02Area and time window.
3. 03Imagery source, resolution and frequency.
4. 04Label source, size and owner.
5. 05Success measure and minimum score.
6. 06Pilot area, timeline and decision date.
7. 07Delivery format and owner after launch.

Common pitfalls

• Choosing a model before checking that the data can answer the question.
• Training and testing in the same area, which overstates accuracy.
• Skipping field validation with local knowledge.
• Promising accuracy before seeing any labelled data.
• Ignoring cloud, and discovering too late that few usable images exist.
• Forgetting the maintenance: models and maps age as the land and the sensors change.

A worked example: scoping a wetland-monitoring pilot

A conservation agency wants to track the extent of wetlands in two districts.

1. 01Decision: “Which wetland areas have shrunk by more than 10 percent since 2020, so that we can send inspectors this year?” The users are the agency’s four field officers, and the answer is needed once a year.
2. 02Area and time: the two districts, comparing the dry season of 2020 with the dry season of 2026.
3. 03Imagery: free 10 metre Sentinel-2 data is enough for wetlands that are hundreds of metres across, and the dry seasons have few clouds. Radar is added to detect water below vegetation.
4. 04Labels: field officers mark 300 sample points, and a former survey map is used as a rough guide. A short labelling guide keeps everyone consistent.
5. 05Success: at least 85 percent overall accuracy and 80 percent recall on wetland, tested on whole sub-areas the model never saw. The agency also wants a map users can read in a browser.
6. 06Pilot: one district, six weeks, with a review of the map by the officers on site.
7. 07Delivery: a web map with a layer for each year, a table of change by site and a short methods note.

This scope fits on a page. It tells a data scientist exactly what to build, tells the manager what they will get and tells everyone how success will be judged.

Frequently asked questions

How long should scoping take?

Often one to two weeks, including a workshop and checks on data. It is a small investment that prevents far larger waste.

Can we scope without knowing the accuracy we can achieve?

You can set a target, but treat it as a hypothesis to test in the pilot, not a promise. The pilot’s job is to find out.

Who should own the scope?

A person from the user side, not only the technical team. They must be able to say whether the result will be useful.

What if the labels do not exist?

Plan and budget for creating them. Or consider unsupervised or rule-based approaches for a first look, and be honest about their limits.

A well-scoped GeoAI project feels almost boring. Everyone knows the question, the data, the target and the date. That clarity is exactly what lets the technical work go quickly and the result get used.