Free and open tools for satellite mineral prospecting: a beginner survey

Answers question 3 from the package overview. Audience: the claim holder who has walked the ground, has a geology sheet, and has zero budget for commercial remote sensing or geophysics.

The honest ceiling first. Free multispectral satellite data (Sentinel-2, Landsat) can help you prioritize where to walk. It cannot identify minerals. It cannot detect gold. It will produce false positives in tropical laterite terrain, and it will go blind under canopy. Every map you generate from the tools below is a hypothesis you must test on the ground, not a result.

With that fixed in mind, here are the tools that actually work on zero budget.

Tool by tool

QGIS

What it is. A free, open-source desktop GIS that runs on Windows, macOS, and Linux. Download from qgis.org. No account needed.

What it is good for. Loading Sentinel-2 or Landsat scenes (including COGs streamed directly over HTTP), doing band arithmetic in the Raster Calculator (for example computing an iron-oxide ratio like Band4/Band2 or a clay index like Band11/Band12 for Sentinel-2), overlaying your geology sheet, and digitizing AOIs or field observations. The Semi-Automatic Classification Plugin (SCP) (install from the QGIS plugin manager) adds a guided workflow for atmospheric correction, band stack download from multiple sensors, and basic supervised/unsupervised classification. It is the single most capable free tool for this workflow if you are willing to spend a few days learning the interface.

The catch. QGIS is local: every scene you want to analyze must be downloaded first, and a full Sentinel-2 granule is 700 MB to 1 GB. Raster Calculator is slow on large scenes. SCP's supervised classifier needs training samples you collect yourself. The learning curve is real but well-documented; the SCP manual is thorough.

Copernicus Browser (formerly EO Browser)

What it is. A browser-based viewer for Sentinel data maintained by Sinergise and ESA, at browser.dataspace.copernicus.eu. Free account, no software install.

What it is good for. Quickly rendering custom band combinations and ratios on the fly over any date range. You can write a short JavaScript snippet to display a false-colour composite that highlights iron-oxide or clay alteration and visualize it over your AOI in seconds. The EO Browser script library (under "Custom script") includes community-written mineral-index scripts. Good for rapid scene selection before committing to a download.

The catch. The free tier limits how many scenes you can request and export per month. You cannot do bulk processing or stack multiple dates for a temporal composite. It is a viewer, not a processing environment: you see the result but cannot chain it into a reproducible workflow.

Google Earth Engine (GEE)

What it is. Google's cloud-based geospatial analysis platform at earthengine.google.com. Free for non-commercial use after account approval (approval typically takes a few days to a few weeks). Provides access to a petabyte-scale archive: Sentinel-1, Sentinel-2, Landsat Collection 2, ASTER, SRTM, Copernicus DEM, and much more.

What it is good for. Writing scripts (JavaScript in the Code Editor, or Python via the ee library) that filter imagery by date and cloud cover, compute indices across multiple scenes, and visualize or export results. The archive depth and server-side processing mean you can compute a median composite of 50 scenes in a minute without downloading anything. For a beginner the Code Editor is the most approachable entry: a browser-based IDE with inline documentation, a large community, and thousands of public tutorials.

The catch. Three catches. First, the learning curve: you need to learn the GEE data model (ee.Image, ee.ImageCollection, map-reduce idioms) before you can do anything non-trivial. Second, the license: GEE is free only for non-commercial research and education. If your prospecting claim is a commercial venture, you are in a grey area and should read the terms carefully. Third, the walled garden: your scripts, exports, and analysis live inside Google's infrastructure. If Google changes the terms or the service, your workflow disappears. Exports to Google Drive are limited in size per day on the free tier.

STAC + Python (rasterio, rioxarray, stackstac, pystac-client)

What it is. A scriptable route using open Python libraries to query SpatioTemporal Asset Catalogs (STAC) and stream COG data directly from cloud storage. Two good free STAC endpoints: Microsoft Planetary Computer (planetarycomputer.microsoft.com) and Element84's Earth Search (earth-search.aws.element84.com). Both serve Sentinel-2 L2A, Landsat Collection 2, Copernicus DEM, and more. No download required: you can stream only the bands and the spatial window you need.

What it is good for. Reproducible, scriptable analysis. With pystac-client you query for scenes by AOI, date, and cloud cover. With stackstac you assemble a lazy xarray DataArray across multiple dates without downloading full granules. With rioxarray and rasterio you do windowed reads, reproject, and compute indices. This is the closest free equivalent to GEE's processing power, except it runs on your laptop (or any notebook environment like Google Colab, which is free).

The catch. You need to be comfortable with Python. There is no GUI. Debugging environment setup (GDAL, PROJ, libgeos) on Windows can be painful; using a conda environment or running in Google Colab avoids most of that. Throughput is limited by your internet connection and the free-tier rate limits of the STAC endpoints; large mosaics over a slow connection can be slow.

ESA SNAP

What it is. The Sentinel Application Platform, free from step.esa.int/main/toolboxes/snap. A desktop application that handles preprocessing of ESA Sentinel data, especially Sentinel-1 SAR.

What it is good for. Sentinel-1 SAR preprocessing: applying orbit files, thermal noise removal, radiometric calibration, speckle filtering (Lee, Refined Lee, Gamma MAP), and terrain correction using a DEM. These steps are mandatory before SAR backscatter is interpretable. For the structural lineament arm of this research package, getting Sentinel-1 onto a terrain-corrected geocoded grid is the starting point. SNAP's graph builder lets you chain these steps and re-run them with one click.

The catch. SNAP is slow and memory-hungry on large scenes. The interface is not intuitive. For optical data (Sentinel-2, Landsat) SNAP offers less advantage over QGIS or Python. It is essentially mandatory for SAR work and mostly skippable for multispectral-only workflows.

USGS EarthExplorer, LP DAAC, and ASF

What they are. Three USGS/NASA data portals that provide access to datasets not available through Planetary Computer or Earth Search.

What they are good for. Accessing data that has no STAC endpoint yet, especially ASTER and EMIT hyperspectral scenes. EMIT in particular is one of the most scientifically valuable free mineral-mapping datasets ever released: 380-band hyperspectral at 60 m from the ISS, with surface mineralogy products already computed by the EMIT team.

The catch. Downloads are bulk and the interfaces are clunky. ASTER and EMIT scenes are not organized into neat STAC collections the way Sentinel-2 is. You may spend a long time clicking through search results. The Earthdata account is free and takes about two minutes to create.

ASTER: the dead-SWIR problem

This deserves its own callout. ASTER has 14 bands including six shortwave infrared (SWIR) bands at 30 m that are highly sensitive to clay, carbonate, and hydroxyl mineralogy. On paper it is ideal for alteration mapping.

The catch: the ASTER SWIR detector failed in April 2008. Every ASTER scene acquired after that date has dead (black) SWIR bands. Since ASTER launched in 1999, the usable SWIR archive runs from 2000 to early 2008 — about eight years. Before downloading any ASTER scene for alteration work, check the acquisition date. If it is after April 2008, the VNIR bands (bands 1-3) are still alive and usable for structural and iron-oxide work, but the SWIR bands (4-9) are dead and should be ignored. Many tutorials online do not mention this. Do not waste hours trying to correct dead SWIR.

Where Folia fits

Folia's approach is different in kind from the tools above, not just in degree. The core idea is a declarative, forkable, inspectable recipe: a YAML specification that captures not just the output (a band-ratio map) but the exact inputs, the exact transforms, the exact thresholds, and the provenance chain from raw satellite archive to final product. The recipe reruns anywhere, requires no account with any cloud provider, and produces the same result on a laptop or in a cloud batch job. When someone disagrees with a threshold or wants to extend the method, they fork the recipe and run their version alongside yours. Human-in-the-loop calibration, for example annotating field observations that adjust the iron-oxide confidence score, is a first-class part of the workflow.

Contrast that with the other tools here: GEE is powerful but your script and results live inside Google's infrastructure under a non-commercial license and the walled environment makes reproducibility fragile; QGIS is local, manual, and produces outputs that are hard to share in a way that lets someone else reproduce the exact steps; SNAP preprocessing chains are not inherently shareable. Folia's angle is that the recipe is the primary artifact, and the map is its output.

For the Zvishavane package, the recipes in iron-oxide-gossan, alteration-mapping, and structure-lineaments are the proof-in-progress: each one documents what was fetched, how it was processed, and what the result means. Folia is early, this package is one of its first real mineral-prospecting applications, and results will be updated as ground truth comes in.

Short summary of the contrast:

  • GEE: massive archive, fast cloud compute, great for exploration, but non-commercial license, JS/Python learning curve, walled environment, not self-hostable.
  • QGIS: powerful local GIS, full manual control, good for visualization and overlay, but no cloud scale and no built-in reproducibility contract.
  • STAC + Python: reproducible and scriptable, runs anywhere, but you assemble the toolchain yourself with no shared recipe format.
  • Folia: declarative recipes on free COG/STAC data, inspectable provenance, human-in-the-loop calibration, self-hostable, still early.

Realistic beginner workflow on zero budget

This is the order of operations that will give the highest return on time for a shoestring explorer. Each step feeds the next.

  1. Start with the geology map. Before opening any software, read the Geological Survey sheet for your area. Mark every lithological contact (especially mafic/ultramafic to felsic transitions), every fault and shear zone marked, and every known occurrence. These contacts and structures are your primary target zones. Everything from satellite is a filter applied on top of geology, not a replacement for it.

  2. Download a DEM and map lineaments. Use the Copernicus GLO-30 DEM (freely available via Planetary Computer or OpenTopography). In QGIS, generate hillshades at three or four solar azimuths (0, 45, 90, 135 degrees) at a low sun angle (20-30 degrees elevation). Lineaments (ridgelines, drainage offsets, linear shadows) that appear in two or more azimuths are real structural features; ones that appear in only one azimuth are illumination artifacts. Overlay these on your geology sheet. Where DEM lineaments align with mapped faults or shear zones, mark them as high priority.

  3. Compute a simple iron-oxide index on Sentinel-2. Use Sentinel-2 L2A Band 4 (red) divided by Band 2 (blue), or the Landsat equivalent. In QGIS Raster Calculator this takes ten minutes. Apply a vegetation mask first: anywhere NDVI (Band 8 minus Band 4, divided by Band 8 plus Band 4) is above about 0.3, set the iron-oxide index to no-data. What remains is exposed soil or rock. High values in your AOI are gossan candidates or laterite (both look the same from space).

  4. Overlay everything. In QGIS, stack your geology map, your DEM lineament traces, your iron-oxide raster, and any known gold occurrences from the literature. The targets worth sampling on the ground are where all three signals coincide: a mapped structure, a DEM lineament, and an iron-oxide anomaly on exposed ground, inside or adjacent to the prospective lithology.

  5. Prioritize sampling, not identification. Do not try to distinguish gossan from laterite from the satellite data alone. That distinction requires field observation and, if needed, a hand lens and acid bottle. The satellite work gives you a ranked list of locations to visit. Go to the top of the list first. Describe what you see, collect a small chip, and record the GPS point. That observation becomes your ground truth and feeds back into recalibrating the satellite indices (this is the human-in-the-loop step Folia is built for).

  6. Add SWIR only if vegetation is sparse and scenes are pre-2008 (ASTER) or you have EMIT coverage. If your target area is in an EMIT tile (check LP DAAC or earth-search.aws.element84.com), the hyperspectral mineralogy maps from the EMIT team are worth overlaying. They distinguish kaolinite from chlorite from carbonate at 60 m. For the Mberengwa belt, canopy and laterite are the dominant confounds; EMIT is useful on exposed ridgelines and old workings, less so under woodland.

Limits: what free satellite cannot do

No gold detection. Gold has no diagnostic spectral feature in VNIR or SWIR. You are mapping the alteration halos (iron-oxide, clay, carbonate) that are statistically associated with gold mineralization in greenstone belts. The association is real but the false-positive rate is high.

Laterite looks like gossan. Tropical weathering produces red-brown lateritic soils across vast areas of the African craton. A laterite horizon and a gossan have almost identical Sentinel-2 spectral signatures. Only field examination (or a detailed geochemical sample) distinguishes them. Every iron-oxide anomaly in the Mberengwa area should be assumed to be laterite until proven otherwise.

Vegetation masks the signal. Under even light tree cover, the satellite sees canopy chlorophyll, not rock or soil. The NDVI mask described above removes vegetated pixels entirely. This means large parts of your AOI will simply be masked out. Anomalies near cleared areas, old workings, or exposed ridgelines are more reliable than anomalies under any vegetation.

No mineralogy without SWIR or hyperspectral. Sentinel-2 has two SWIR bands (Band 11 at 1610 nm and Band 12 at 2190 nm). These bands respond to clay and hydroxyl minerals in a broad way but cannot distinguish kaolinite from sericite from chlorite. ASTER's six SWIR bands can (on pre-2008 scenes only). EMIT's 380 bands can. For the specific greenstone-belt alteration assemblage (sericite-chlorite-carbonate-listwaenite), free multispectral data gives you a clay-presence signal, not a mineral-species signal. Do not report "kaolinite alteration" from a Sentinel-2 SWIR index: you can only report "hydroxyl anomaly consistent with clay or carbonate alteration."

No depth information. Satellite observes surface reflectance. Mineralization at depth is invisible. A gossan outcrop indicates that alteration reached the surface here; it does not mean the mineralized zone persists at depth, and it does not indicate thickness or grade.

Spatial resolution is coarser than most field features. Sentinel-2 is 10-20 m per pixel. A typical lode-gold quartz vein is decimetres to a few metres wide. The satellite cannot see the vein; it may see the alteration halo around it if that halo is wide enough and exposed enough. Targets will always be sub-pixel in the dimension of interest.