mapsmith-ai/MapSmith

**Ask a question about your data. Get an analysis — and the record that proves it.**
Most GIS servers hand an agent a tool to run. MapSmith takes the question, works out the
*analysis* — usually several operations, in an order that has to be right — validates the
plan before a single file is touched, runs it, and leaves a record of every step — which
bytes went in, with which parameters and CRS decisions, and which checks ran — that somebody
else can read afterwards and rerun to confirm.
Try it
Point any MCP client at MapSmith (one JSON block) and ask, in your own words:
> Which parcels lie within 1.5 km of the river and sit at 120 m or lower? Give me the mean
> elevation and the ground area of each.
That is five operations, two coordinate systems and forty-eight checks. **What actually
happens is below** — the plan, the step that gets
rejected for reading something a later step produces, the CRS decision behind every metric
step, and an answer you can work out on paper before MapSmith sees the files. That
rejection is structural, and so is every other one: a plan that is well formed and answers
the wrong question runs instead, which is
measured and written down further down this page.
The operations are executed by GeoPandas, DuckDB Spatial, exactextract and Whitebox
Workflows — never by the model that asked for them. Every dataset lands on disk next to a
lineage manifest: inputs with checksums, the exact parameters, the CRS decisions and *why*,
engine versions, and the deterministic checks that ran on the result.
**mapsmith.dev** — a real terrain analysis and the manifest that came
with it. Both are build products: the figure is rendered from GeoTIFFs MapSmith writes, so the
page cannot drift from what the software does.
The manifest is a specified format, not
MapSmith's private output: JSON Schema, a toolchain-free validator, a conformance suite, and a
hundred-line emitter that never imports MapSmith. Records carry spec_version, and CI validates
real MapSmith output against the spec's own validator. The specification is archived and citable
as 10.5281/zenodo.22205213, a concept DOI that
resolves to the latest *archived* draft. Records written by 0.8.0 and 0.9.0 declare 1.0.0-draft.10, and
0.7.x's declare 1.0.0-draft.8; if the DOI shows an earlier one, the archive has not caught up, and the
repository holds the text they are written against. The names MapSmith puts
in a record beyond the ones the specification defines — every extension check name, and every
extension field in crs_decisions with the reason it is not a synonym of a key the specification
already has — are listed in docs/manifest-vocabulary.md,
generated from the source rather than maintained by hand.
Evidence before promises. A correctness suite in its own organisation,
**Argleton**, grades MapSmith on thirty-one traps whose answers are
computed on paper before any system runs: **0.00 silent errors, nothing skipped**, against
0.9032 for the obvious way of writing the same code. The runs from 2026-08-30 to 2026-09-15 said
0.00 too, and on one trap they were wrong: its truth was wrong in MapSmith's favour for 26 days, the error was ours
twice over, and the erratum says so. Every run since 2026-09-26, the current one
included, is scored against the corrected truth. Getting here cost seven defects the suite sent back, and they are listed. Alongside it: an A/B on GABench whose
headline is a null result — with the analysis that took our own positive number apart —
notebooks on a real USGS DEM of Mount St. Helens, an
in-chat map panel that shows the verification status of
every layer it draws, and a
measurement of our own tool discovery that retracted two numbers
this page had already published — including the one in the bullet list below.
A whole analysis, start to finish
This is the thing MapSmith is for, and it is not a single tool call. One question — six
parcels, a river, an elevation grid — becomes a plan of five operations chosen out of 78,
validated before anything runs, executed step by step, and recorded: the search that
narrowed the catalogue, the arguments that mattered, the CRS decision behind each metric
step, and the checks that ran on every result.
Nothing in this section is drawn. benchmarks/worked_example.py builds fixtures whose answer can
be worked out on paper, asks the catalogue in the words of the problem, validates and runs the
plan, reads the manifests, and writes what follows; tests/test_worked_example.py fails if this