Mineral exploration machine learning is a reading list with forks in it

Two markdown files, no code, no install

The whole repository is README.md plus summary.md, so there is nothing to install, nothing to build, and no entry point to call. What it is instead is a curated index of resources for mineral exploration and machine learning, chosen for code and examples that the author found useful or interesting in practice. That framing matters, because a personal list carries selection bias that a standard does not: the argument for each entry is that the author tried it, not that a community agreed.

The index is organised by task rather than by library, with sections for Prospectivity, Geology, Natural Language Processing, Remote Sensing, Data Quality, Community, Cloud providers, Domains, Overview, Web Services, Data Portals, Tools, Ontologies, Books, Datasets, Papers, Other, and General Interest. The ordering of those headings is itself a statement about the field. Ontologies and Data Quality sit beside TorchGeo and prospectivity frameworks, which tells you what the author thinks the job is made of.

Suggestions are welcome through a discussion, an issue, or a pull request, so the list is meant to grow. There are no GitHub releases, and the last push is dated 2026-09-26.

Fork links are the author's modified copies

The README explains its own oddest feature up front: links that currently point to a fork of a repository are there because the author changed something to use and put the fork in the list for reference. That single sentence changes how every entry should be read. A link is not automatically a recommendation for upstream, and in several cases the upstream project is the one to actually use.

The scale of it is noticeable, because the author's own repositories appear throughout the framework list: the UNCOVER-ML framework with its Geo-Wavelets companion, PySpatialML for raster machine learning output, Geo Deep Learning described as a simple deep learning framework based on RGB, AIDE for disentangling extremes, a truly spatial random forest implementation, CAST for spatio-temporal models in R, and two Perceiver repositories. A reader who wants to know which of these are established tools and which are personal experiments has to check each link individually, since the list draws no line between them.

That mixed status is also the list's practical value. A framework the author had to modify to fit geospatial raster work is a framework with a known rough edge, and finding that out from the author is cheaper than finding it out after a week of debugging.

The author argues the modelling is the small part

One sentence does more to explain the list's shape than the table of contents does: resources are also given for data analysis, transformation and visualisation because that is most of the work. The index then backs that up with sections that have nothing to do with neural networks, including Data Quality, Data Portals, Web Services, Cloud providers, Ontologies, and General Interest.

The Natural Language Processing section sits in the same list as the imagery models, which is another sign of what exploration work involves: the geology reports and assay records that describe an area are not structured data, so turning them into something a model can consume is a genuine part of the pipeline rather than a prelude to it.

Reading the headings together gives an honest picture of the field as one practitioner sees it. The machine learning entries are the part everyone writes about, and the coverage around them, ontologies, data portals, quality control, and cloud cost, is the part that determines whether any of it finishes. A list built this way is not a ranking of frameworks, it is a map of the work.

Three different kinds of tool share one section

The frameworks section mixes three families that are usually filed apart. Raster and vector machine learning pipelines come first: UNCOVER-ML with Geo-Wavelets, ML-Preprocessing, Landshark for large-scale spatial inference with tensorflow, GIS ML Workflow, the EIS Toolkit for mineral prospectivity mapping from the EIS Horizon EU Project, PySpatialML for raster prediction written to geotiff, scikit-map, and GeoStat Framework for kriging.

The second family is deep learning on imagery and geospatial foundation models: TorchGeo as a PyTorch library for remote sensing models, terratorch for fine-tuning geospatial foundation models, TorchSpatial, torch-harmonics for differentiable signal processing on the sphere, geodl, Geo Deep Learning, ExPloRA for parameter-efficient adaptation of vision transformers under domain shift, CoreJepa for remote sensing, the Perceiver implementations, and Senseiver for field reconstruction from sparse observations.

The third family is classical statistics that keeps reappearing because the deep learning does not replace it: a truly spatial random forest, pyClusterwise for clustering under uncertainty, CAST in R, and the kriging work under GeoStat Framework. Nothing in the list argues for choosing one family over the others, which is arguably the most useful thing about it: the grouping is by availability and personal experience, not by a theory of what should win.

Georeferencing old geological maps gets its own cluster

The DARPA block is the most specific part of the list because it follows one competition problem all the way through. Uncharted T1 is listed for automated feature extraction and georeferencing of geologic maps, which is the step where a scanned map becomes a spatial layer, and it carries training data hosted in the USGS data catalogue. QueryPlot is listed for generating mineral evidence maps from geological queries, with a paper link for each.

That pairing explains something about the data problem. Machine learning prospectivity work is frequently starved of labelled data because the labelled source is a geological map, and geological maps are images that also need to be georeferenced before they can be sampled. Treating digitisation as its own solved problem, with its own repository, dataset, and paper, is what makes the rest of the pipeline possible.

The links here are also the ones that age worst, since a competition subproject, a repository branch, and a hosted dataset have three different expiry habits. Check that the training data still resolves before planning around it.

Two broken links sit next to real dead ends

The competition info link under the DARPA heading points at a file URL inside a Downloads folder on the author's own machine, so it resolves for nobody else. That is not a subtle failure: it is a local path left in a published list. The geodl entry appears twice under different destinations, once pointing at an eartharxiv repository record and once at a GitHub repository, with the second described as semantic segmentation of geospatial data using convolutional neural network based deep learning. Two entries, one name, two targets, no explanation of which to use.

There is also a copy and paste artefact in one of the paper titles, which repeats the phrase about generating mineral evidence maps from geological queries twice inside the same string. Small, but it is the kind of thing that tells you the list is maintained by a person editing in a hurry rather than by a script.

The visible text stops partway through the R section, at an incomplete arXiv link, so the remainder of the listing after that point is not readable here. Treat the frame list, the tools, the ontologies, and everything past the truncation as unverified until you open the repository yourself. None of this makes the list less useful, it just makes the difference between a pointer and a verified link worth checking.

Prospectivity mapping is the task the rest serves

Prospectivity is the first section in the table of contents, which is a deliberate ordering. Mineral prospectivity mapping is the actual objective: scoring ground for where a deposit is worth looking, given layers of geological, geophysical, and geochemical evidence. Everything else in the list is machinery for producing those layers or for turning them into features.

The dedicated tooling for that task is the EIS Toolkit, a Python library for mineral prospectivity mapping from the EIS Horizon EU Project, and the UNCOVER-ML framework that sits at the top of the framework list with its own wavelet component. The geology section and the remote sensing section supply the inputs, while datasets, data portals, and web services supply the raw material.

For someone asking whether machine learning is worth applying to exploration at all, this ordering is the honest answer to start from. The task is a spatial prediction problem with incomplete and heterogeneous evidence, which is a good fit for the raster pipelines and the spatial forest, and a poor fit for treating a map image as a photograph.

Map of Github and DeepWiki orient you before the list does

Two orientation tools sit above the framework section. The Map of Github link is a graph visualisation pinned to geographic coordinates, which is a fast way to see the neighbourhood of a repository rather than reading a list of names. DeepWiki is pointed at as an automagic wiki style analysis of a repository using a language model, which is useful for sizing up an unfamiliar codebase before committing time to it.

Both choices say something about how the list was assembled. Graph views and generated summaries are research tools, used to find candidates and check what they are, which fits a collection built from what one person found useful rather than from a curriculum.

The Cloud providers section is worth pairing with that, since compute for raster prediction at scale is a cost decision rather than a technical one. Anyone working through this list should settle which steps run on a laptop and which need a rented instance before choosing a framework, because the pipeline stages that dominate cost are the ones that touch every pixel of every layer.

Editorial conclusion

This repository is worth an hour from anyone starting machine learning work on mineral prospectivity, because it names the frameworks, the foundational model tooling, and the boring data plumbing that the job actually needs. It is not a library, it carries no license anyone can build on, and its fork links describe one practitioner's modified copies rather than upstream releases. Before you plan a project around an entry, open the link and check whether it resolves to upstream or to a personal fork.

Frequently asked questions

Official sources

1. Issues
2. README
3. RichardScottOZ/mineral-exploration-machine-learning on GitHub