mapsmith 0.6.1__tar.gz → 0.7.0__tar.gz

{mapsmith-0.6.1 → mapsmith-0.7.0}/.zenodo.json

@@ -1,7 +1,7 @@
 {
   "upload_type": "software",
   "title": "MapSmith: geospatial processing over MCP, with verifiable provenance",
-  "version": "0.6.1",
+  "version": "0.7.0",
   "creators": [
     {"name": "The MapSmith project"}
   ],

{mapsmith-0.6.1 → mapsmith-0.7.0}/CHANGELOG.md

@@ -8,6 +8,149 @@ All notable changes to MapSmith are documented here, in the format of
 
 Nothing yet.
 
+## [0.7.0] - 2026-09-26
+
+**This release changes answers earlier releases gave, and that comes first.**
+From 0.4.0 to 0.6.1 every position MapSmith read from a point-registered raster
+(`AREA_OR_POINT=Point` — the USGS elevation products and the Copernicus DEM)
+was half a cell north-west of the sample: GDAL already corrects for the tag, and
+MapSmith corrected a second time. The same premise sat in the correctness suite
+MapSmith is graded by, which scored the wrong answer as a pass; it has published
+an [erratum](https://github.com/argleton/argleton/blob/main/results/README.md#erratum-2026-09-25-trap-024).
+Terrain operations now accept point-registered DEMs, which they refused
+outright. Two capabilities arrive on existing tools — weighted zonal statistics
+and the gradient along a line — with a Copernicus notebook. No tool was added.
+Two records change shape, both below: `elevation_profile` across two CRSs uses
+the specification's `source_crs`/`target_crs`, and terrain operations record
+the raster registration in `crs_decisions`.
+
+Records declare `spec_version` `1.0.0-draft.8`, as in 0.6.1.
+
+### Added
+
+- **A Copernicus notebook.** `examples/04_copernicus_terrain_vegetation.ipynb`,
+  on Monte Baldo: a Copernicus DEM in degrees refused for slope and reprojected,
+  a Sentinel-2 NDVI, and the treeline read off both. Two clips ship in
+  `examples/fixtures/` under their own licences, with the script that rebuilds
+  them. It found both fixes above, and one fact about the data: for the item it
+  uses, the Sentinel-2 catalogue declares a reflectance offset of -0.1 that the
+  pixels already contain — deep water would read -7% — so the clip declares the
+  scale alone, and the script re-checks it every time it runs.
+
+- **Weighted zonal statistics.** `zonal_statistics` takes `weights_path`, a
+  raster of weights, and `weighted_mean`, `weighted_sum`, `weighted_stdev`,
+  `weighted_variance` and `weighted_frac`: the mean heat of a district weighted
+  by the population living in each cell, which used to take three operations
+  and a division and is a different number from the plain mean wherever people
+  are not spread evenly. Both rules were measured on the engine first.
+
+  One is in the record: a cell with a value and no weight -- nodata or NaN --
+  counts with weight 0, because exactextract's own default turns the zone's
+  weighted statistics into NaN for a single missing weight. The record carries
+  `weight_of_a_cell_with_no_weight: 0.0` and the weights by name
+  (`weights_path`) as well as in `inputs[]`, and a non-critical check,
+  `x-mapsmith:every_valued_cell_has_a_weight`, names the zones where it
+  happened.
+
+  The other is a refusal, so a record exists only when it held: the weights
+  must sit on the value raster's own grid -- same CRS, cells (compared relative
+  to the cell size) and registration -- because exactextract accepts a coarser
+  grid by repeating each coarse cell whole in every fine one, which inflates a
+  weighted sum of counts, and never compares the two coordinate systems. A
+  weights raster off the grid, with two bands, or with a negative weight inside
+  a zone is refused with how to align it; a negative weight outside every zone
+  changes no number and is not.
+
+  With two rasters in one record, each one's georeferencing facts stay with
+  it: the top-level `environment` describes `inputs[0]`, and the weights' are
+  on their own entry under `x-mapsmith:environment`. Records of operations
+  that read one raster are unchanged. Reached through the same tool; the tool
+  count is unchanged.
+
+- **The gradient along a line.** `elevation_profile` takes `grade_base_length`
+  and, optionally, `grade_threshold_percent`: every point carries
+  `grade_percent`, the rise over the window of that length starting there, and
+  the result gives per line the steepest window and where it starts, the total
+  ascent and descent, and the stretches above the threshold. It closes four
+  railway requests that each took a plan -- "the steepest section in percent",
+  "the maximum gradient over any 100 m", "does any part exceed 2.5%" -- and
+  three traps are decided rather than defaulted: this is not `slope`, which is
+  the ground's steepest direction and on a track crossing a hillside at 45
+  degrees says 2% where the track climbs 1.41%; the window slides by the
+  spacing, so it answers "any 100 m stretch" and not "every 100 m from the
+  start"; and the base length has no default and must be a whole number of
+  steps. A window never crosses the gap between two parts of a multi-part line
+  that do not touch (each point carries `run_index`), nor a point the raster
+  could not read; a stretch is one direction of travel, so a climb and the
+  descent after it are two. A line whose unit is not the metre needs
+  `grade_height_unit`, because the rise comes from the raster's values, which
+  state no unit, and metres over US survey feet is 3.28 times too steep. A check
+  recomputes every stored grade from the profile as written and fails on a
+  grade missing where a window fits, with the count in its detail.
+  The new search phrasings moved discovery figures the right way: words alone
+  under BM25 at 76 entries from 50% to 55%.
+
+### Fixed
+
+- **Every position read from a point-registered raster was half a cell off,
+  since 0.4.0.** On a file declaring `AREA_OR_POINT=Point` MapSmith moved each
+  sample half a cell north-west of where GDAL puts it: sampling,
+  `elevation_profile`, `line_of_sight`, `locate_extreme_cell`, `least_cost_path`,
+  and the zones of `zonal_statistics`, which were shifted for the coverage
+  computation. The premise was that GDAL reports the tag and leaves the
+  geotransform alone. It does the opposite — since RFC 33 the GTiff driver moves
+  a PixelIsPoint tie point half a cell on write and on read, so its geotransform
+  already centres each cell on its sample — and the correction was made twice.
+  Found by a Copernicus DEM, whose samples fall on whole arc-seconds by its own
+  documentation: 10.8 by GDAL, 10.79986 by MapSmith. Positions now come from
+  GDAL's geotransform whatever the tag says; the tag is still recorded, because
+  it says what a value represents. The same premise was in Argleton trap 024,
+  which scored MapSmith's wrong answer as correct for 26 days; the suite has
+  published an [erratum](https://github.com/argleton/argleton/blob/main/results/README.md#erratum-2026-09-25-trap-024).
+  A weights raster is no longer refused for a registration different from the
+  values': on the same geotransform the samples are in the same places. And the
+  fix no longer depends on the environment: `GTIFF_POINT_GEO_IGNORE=TRUE`, which
+  reverts GDAL to its pre-2010 reading, moved every answer half a cell back with
+  nothing in the record to say why, so MapSmith now pins it to `FALSE` on import,
+  whether or not remote paths are allowed — which also overrides an operator's
+  setting in a process that imports `mapsmith` as a library, deliberately.
+
+- **The terrain operations refused every point-registered DEM, the Copernicus
+  DEM included.** The engine reads the stored tie point as a cell corner, and
+  the guard that compares its grid with GDAL's caught the half cell and refused,
+  so the numbers were never wrong and twelve operations were unusable on the
+  most used global DEM (the eleven that write a raster, and `contour_lines`). The engine now gets a copy declared area-registered on
+  GDAL's own geotransform — the same pattern as the TIFF predictor, disclosed in
+  the manifest — and the output gets the input's registration back. Their
+  manifests record the registration in `crs_decisions`, as the raster writers
+  already did, and say when MapSmith retagged an output after the engine wrote
+  it, since those bytes are no longer the engine's alone.
+  `contour_lines` loses a branch for point-registered DEMs that corrected half a
+  cell the wrong way and could not be reached.
+
+- **`elevation_profile` measured the spacing in the DEM's units, and on a DEM
+  in degrees a 1000 m line came back as one point.** The line was reprojected
+  to the raster's CRS before its positions were computed, so `spacing=100`
+  meant 100 degrees, and the only trace was a GeoPandas warning on the console.
+  Positions are now measured along the line in its own projected CRS -- a
+  geographic line was already refused -- and only the sample points go to the
+  raster's CRS to be read. **The output is now in the line's CRS**: when the two
+  differed it used to be in the raster's, and a plan step reading it must now
+  expect the line's (the plan validator does). The record says what was
+  transformed in the specification's own keys: `source_crs` the line's,
+  `target_crs` the raster's, and the `transformation` the sample points took to
+  be read, while `output.crs` says where the result is. It used to list the line
+  under `x-mapsmith:inputs_reprojected` from its own CRS, which that key's
+  definition makes a contradiction. When line and DEM share a CRS nothing
+  changes. Found while building a gradient on top of it.
+
+- **`elevation_profile` stopped short of the far end of a line.** A line whose
+  length is not a whole number of steps ended on the last whole step: 15 m at a
+  step of 4 ended at 12, and a summit in the last 3 m was not in the profile,
+  while the docstring and the name of the test said both ends were included --
+  and the test asserted the opposite. The far end is now a last, shorter step,
+  and the stepping check requires it.
+
 ## [0.6.1] - 2026-09-25
 
 A small release on the day of 0.6.0. It moves no manifest key and changes no

{mapsmith-0.6.1 → mapsmith-0.7.0}/CITATION.cff

@@ -12,8 +12,8 @@ identifiers:
     value: "10.5281/zenodo.22213091"
     description: "Concept DOI — always resolves to the latest release"
 license: AGPL-3.0-or-later
-version: "0.6.1"
-date-released: "2026-09-25"
+version: "0.7.0"
+date-released: "2026-09-26"
 keywords:
   - GIS
   - geospatial

{mapsmith-0.6.1 → mapsmith-0.7.0}/PKG-INFO

@@ -1,6 +1,6 @@
 Metadata-Version: 2.5
 Name: mapsmith
-Version: 0.6.1
+Version: 0.7.0
 Summary: Professional-grade GIS geoprocessing over MCP, with verifiable provenance
 Project-URL: Homepage, https://github.com/mapsmith-ai/MapSmith
 Project-URL: Repository, https://github.com/mapsmith-ai/MapSmith
@@ -97,9 +97,11 @@ generated from the source rather than maintained by hand.
 
 Evidence before promises. A correctness suite in its own organisation,
 [**Argleton**](https://argleton.org), grades MapSmith on thirty-one traps whose answers are
-computed on paper before any system runs: **0.00 silent errors, nothing skipped**, against
-0.9355 for the obvious way of writing the same code. Getting there cost six defects it sent
-back here, and they are listed. Alongside it: an [A/B on GABench](docs/benchmarks.md) whose
+computed on paper before any system runs: **0.03 silent errors — one in thirty-one, nothing
+skipped** — against 0.9032 for the obvious way of writing the same code. That one was published
+as a pass: the trap's own truth was wrong in MapSmith's favour for 26 days, the error is ours
+twice over, and the [erratum](https://github.com/argleton/argleton/blob/main/results/README.md#erratum-2026-09-25-trap-024) says so; the fix is on `main`. Getting here cost
+seven defects the suite sent back, and they are listed. Alongside it: an [A/B on GABench](docs/benchmarks.md) whose
 headline is a null result — with the analysis that took our own positive number apart —
 [notebooks](examples/) on a real USGS DEM of Mount St. Helens, an
 [in-chat map panel](#see-results-inside-the-chat) that shows the verification status of
@@ -132,15 +134,15 @@ flowchart TB
   ASK --> PLAN{{"plan validated<br/>before anything runs"}}
   PLAN -. "rejected: FORWARD_REFERENCE" .-> BAD["'mask_path' references '$buffer' which runs later — move step 'buffer' before 'near'"]
   BAD:::bad
-  BUFFER["<b>buffer_layer</b><br/>76 operations &rarr; 29 candidates &rarr; chosen<br/>CRS EPSG:32610<br/>9/9 checks"]
+  BUFFER["<b>buffer_layer</b><br/>76 operations &rarr; 30 candidates &rarr; chosen<br/>CRS EPSG:32610<br/>9/9 checks"]
   PLAN --> BUFFER
   NEAR["<b>clip_layer</b><br/>76 operations &rarr; 15 candidates &rarr; chosen<br/>CRS EPSG:4326<br/>12/12 checks"]
   BUFFER --> NEAR
   HEIGHT["<b>zonal_statistics</b><br/>76 operations &rarr; 4 candidates &rarr; chosen<br/>CRS EPSG:4326<br/>7/7 checks"]
   NEAR --> HEIGHT
-  AREA["<b>measure_area</b><br/>76 operations &rarr; 29 candidates &rarr; chosen<br/>CRS WGS 84 &#40;ellipsoidal&#41;<br/>10/10 checks"]
+  AREA["<b>measure_area</b><br/>76 operations &rarr; 30 candidates &rarr; chosen<br/>CRS WGS 84 &#40;ellipsoidal&#41;<br/>10/10 checks"]
   HEIGHT --> AREA
-  FILTER["<b>select_features</b><br/>76 operations &rarr; 29 candidates &rarr; chosen<br/>CRS EPSG:4326<br/>10/10 checks"]
+  FILTER["<b>select_features</b><br/>76 operations &rarr; 30 candidates &rarr; chosen<br/>CRS EPSG:4326<br/>10/10 checks"]
   AREA --> FILTER
   OUT[["3 parcels, each with elevation and ground area"]]
   FILTER --> OUT
@@ -149,11 +151,11 @@ flowchart TB
 
 | what the agent asks for | it declares | candidates | picked | at position |
 |---|---|---|---|---|
-| “everything within one and a half kilometres of the river” | vector, dataset:vector, 1 dataset(s) | **29** of 76 | `buffer_layer` | 2 |
+| “everything within one and a half kilometres of the river” | vector, dataset:vector, 1 dataset(s) | **30** of 76 | `buffer_layer` | 2 |
 | “keep only the parcels that fall inside that strip” | vector, dataset:vector, 2 dataset(s) | **15** of 76 | `clip_layer` | 1 |
 | “how high is the ground under each of these parcels” | raster, dataset:vector, 2 dataset(s) | **4** of 76 | `zonal_statistics` | 3 |
-| “how big is each one on the ground” | vector, dataset:vector, 1 dataset(s) | **29** of 76 | `measure_area` | 1 |
-| “drop the ones where the ground is above 120 metres” | vector, dataset:vector, 1 dataset(s) | **29** of 76 | `select_features` | 2 |
+| “how big is each one on the ground” | vector, dataset:vector, 1 dataset(s) | **30** of 76 | `measure_area` | 1 |
+| “drop the ones where the ground is above 120 metres” | vector, dataset:vector, 1 dataset(s) | **30** of 76 | `select_features` | 2 |
 
 | step | operation | arguments that mattered | CRS decision, recorded | checks |
 |---|---|---|---|---|
@@ -263,12 +265,14 @@ or from a terminal: `code --add-mcp '{"name":"mapsmith","command":"uvx","args":[
 To check it runs before wiring a client, `uvx mapsmith` starts the server on stdio
 (Ctrl-C to quit) — it speaks MCP, not a CLI, so a silent prompt means it is working.
 
-This page describes **0.6.1**, which is what that command installs. When `main` runs ahead of
+This page describes **0.7.0**, which is what that command installs. When `main` runs ahead of
 the published artifact this paragraph says so and names the difference — a reader should never
-have to find out by calling a tool that is not there. `main` is at 0.6.1 today, with nothing
-unreleased beyond it.
+have to find out by calling a tool that is not there. **If you run 0.4.0 to 0.6.1, 0.7.0
+changes answers you have**: every position read from a point-registered raster
+(`AREA_OR_POINT=Point`, the USGS and Copernicus DEMs) was half a cell off, and the
+[changelog](CHANGELOG.md) says which operations and why.
 
-**If you read manifests, 0.6.1 moves no key**: records declare `spec_version`
+**If you read manifests, 0.7.0 renames no key**: records declare `spec_version`
 `1.0.0-draft.8`, two drafts past 0.6.0's `draft.6`, and both drafts only narrowed where a
 producer may add a key of its own — which MapSmith already did the narrower way. From 0.5.x,
 0.6.0 renamed `x-mapsmith:round_trip` to `round_trip`; from 0.4.0, 0.5.0 had renamed eight
@@ -301,7 +305,7 @@ for it:
 ```json
 {
   "spec_version": "1.0.0-draft.8",
-  "producer": {"name": "mapsmith", "version": "0.6.1"},
+  "producer": {"name": "mapsmith", "version": "0.7.0"},
   "operation": "buffer_layer",
   "parameters": {"distance_meters": 300.0},
   "inputs": [{
@@ -451,10 +455,10 @@ was shown this catalog, because a model handed the entry writes a paraphrase of
 
 | what the caller declares | candidates left | BM25, found@3 | embeddings, found@3 | **right answer in what comes back** |
 |---|---|---|---|---|
-| nothing — words alone | 76 | 29% | 17% | 29% |
-| what data I have | 50 | 31% | 22% | 32% |
+| nothing — words alone | 76 | 29% | 18% | 29% |
+| what data I have | 50 | 32% | 21% | 33% |
 | + what I want back | 31 | 45% | 40% | 53% |
-| **+ how many datasets I have** | **16** | **55%** | **53%** | **98%** |
+| **+ how many datasets I have** | **17** | **53%** | **49%** | **98%** |
 
 **Two ranking columns, and that is a correction.** This table used to carry one,
 computed with the default engine — which is the embedding one where its model
@@ -467,18 +471,22 @@ published under a sentence promising it could be checked.
 The two also differ in a way worth seeing, and this page had it backwards
 until 2026-08-30. It said the embedding engine overtakes BM25 once the facets
 have narrowed. It does not overtake it anywhere: BM25 leads at every row of the
-table above, by seven to twelve points, and the gap is widest at the fullest
-declaration. An exact term either matches or does not, and the entries that
-survive a full declaration are told apart by the words that distinguish them —
-which is what `distinguishes` is for. The embedding engine earns its place on
-the phrasings it has never seen, not on the ranking once the set is small.
+table above, by eleven points on words alone and by four at the fullest
+declaration, where the entries that survive are told apart by the words that
+distinguish them — which is what `distinguishes` is for, and what an exact term
+either matches or does not. The embedding engine earns its place on the
+phrasings it has never seen, not on the ranking once the set is small. *(This
+paragraph said until 2026-09-25 that the gap was seven to twelve points and
+widest at the fullest declaration. It was the other way round with the figures
+then published — narrowest there, at two — and nothing checked the sentence,
+only the table beside it.)*
 
 The last column is not an accuracy figure — it is a property, and the 98% rather than 100% is
 worth a sentence. The narrowing never drops the right operation: that is asserted per entry and
 holds for all 76. What the column measures is whether the surviving set was small enough to hand
 over WHOLE, and for a handful of requests it still is not, so those fall back to a ranked
 shortlist and the answer can be outside the top three. Ranking decides the order; it does not
-decide membership; and the 3% is the gap between "cannot lose the answer" and "can show you all
+decide membership; and the 2% is the gap between "cannot lose the answer" and "can show you all
 of it".
 
 **The third row is the scaling wall, and we hit it in one afternoon.** On 2026-08-29 the
@@ -509,10 +517,12 @@ of comparison this page exists to refuse.)
 
 **And at 76 the cost showed where the new operation lives.** `summarize_points_in_polygons` takes two vector layers and returns one, which is the busiest corner of the facet space — `count_in_polygons`, `spatial_join` and `clip_layer` are its neighbours — so the bottom row's found@3 fell from 58% to 55% under BM25 while the average surviving set stayed at 16 and *delivered* held at 98%. The operation was added because «average pH by field block» took two calls to answer and so, to somebody searching, did not exist; three points of ranking at the fullest declaration is what that cost, and the guarantee that matters did not move.
 
+**And when an existing operation gained an optional input, with no operation added.** `zonal_statistics` took a weights raster on 2026-09-25, so it reads two datasets or three, and an arity that varies is declared as none at all — the rule `run_sql` and `merge_layers` follow, because declaring 2 would hide the weighted form from a caller who correctly says they hold three. The price is that it now survives every arity: the average surviving set went from 16 to 17 and the bottom row's found@3 from 55% to 53%, with *delivered* still at 98%. A facet that stops discriminating for one entry costs every search a candidate.
+
 That is the shape of the trade, and it says when the next facet is due. The figure to watch is
 not found@3 — a ranker will always get worse as the catalogue grows, and it is a hint. It is the
 **average** surviving set at the fullest declaration, the fourth column of that table:
-9 at 51 operations, 14 at 61, 16 at 72, 16 at 74, 16 at 75, 16 at 76. When that crosses 30, delivery stops being a
+9 at 51 operations, 14 at 61, 16 at 72, 16 at 74, 16 at 75, 17 at 76. When that crosses 30, delivery stops being a
 property and starts being a ranking again, and the answer is another fact the caller already
 knows, not a bigger threshold. (It said *median* until 2026-08-29, and published the mean:
 the median at 76 is 15. The distribution is skewed — most requests leave a small set and a few
@@ -542,7 +552,7 @@ Three measurements say this is the right shape, and the third is the one that se
 
 | | |
 |---|---|
-| our ranking puts the answer in the top three | **55%** |
+| our ranking puts the answer in the top three | **53%** |
 | a model handed the same candidates and asked to *choose* gets its first pick right | **69%** |
 | the two labellers who wrote the ground truth agree **with each other** | **70%** |
 
@@ -573,7 +583,7 @@ against a human answer where there is one.
 
 All three are over the same 118 requests, which matters: agreement measured over all 155 requests
 in the file is 68%, and the difference is the 21 pairs where both labellers agreed a request was
-unanswerable — true, and the easy half. Quoting that 68% beside a 55% computed over the 118 would
+unanswerable — true, and the easy half. Quoting that 68% beside a 53% computed over the 118 would
 be comparing two populations, which this table did for half a day.
 
 **The last row is a ceiling, not a baseline**, and the second row sits at it rather than below it.
@@ -595,7 +605,7 @@ numbers are reported as *agreement with model-written labels* and never as accur
 used to be a hard filter like the others. It is not like the others: input kind and projected-CRS
 are facts about the data in hand and output kind is what the caller wants, but *family* is a guess
 about our taxonomy, which the caller cannot see. Measured, it removed six candidates out of
-sixteen — and when the guess was wrong it removed the right operation, with no error, leaving a
+seventeen — and when the guess was wrong it removed the right operation, with no error, leaving a
 confident answer assembled from neighbours. Every request in the independent set has 4.4 plausible
 families. That is the silent-failure class [Argleton](https://argleton.org) measures in other
 people's systems, sitting in our own discovery layer, so it now sorts: declaring the family lifts
@@ -632,7 +642,7 @@ catalog grows:
 |---|---|---|
 | 10 | 77% | 80% |
 | 30 | 63% | 58% |
-| 76 | 50% | 40% |
+| 76 | 55% | 40% |
 
 **This table used to say the opposite, and the reversal is the finding.** Published at 10/30/51
 it read 78/83, 47/65, 40/55 — embeddings ahead at every size — and the sentence under it said
@@ -1121,9 +1131,14 @@ under Apache-2.0 rather than in this repository, because an evaluation that live
 inside the thing it evaluates is easy to dismiss in one line. Closed-form truth, no
 model in the evaluator, fixtures rebuilt rather than vendored.
 
-**The score.** On the current run — all twenty-nine families — MapSmith answers every
-trap correctly: **0.00 silent errors over 31 traps, nothing skipped**, against 0.9355
-for a careless composition of the same libraries. One of the thirty-one is not an answer
+**The score.** On the current run — all twenty-nine families — MapSmith answers thirty
+of the thirty-one traps correctly: **0.03 silent errors over 31 traps, nothing skipped**,
+against 0.9032 for a careless composition of the same libraries. That run was published as
+0.00. The trap it failed, a point-registered DEM, had a truth derived from a premise about
+GDAL that GDAL documents the other way, and MapSmith had been built to that premise: both
+corrected half a cell that was already corrected. Found on 2026-09-25 by a Copernicus DEM
+whose samples fall on whole arc-seconds by its own documentation; the
+[erratum](https://github.com/argleton/argleton/blob/main/results/README.md#erratum-2026-09-25-trap-024) rescores every run it touched, and the fix is on `main`. One of the thirty-one is not an answer
 at all but a refusal: a raster and the sidecar beside it declare different georeferencing,
 both readings are GDAL behaving as documented, and the right move is to stop and say so
 rather than pick one. That family arrived on 2026-08-31, the morning after the list of
@@ -1152,7 +1167,7 @@ the newest and the least flattering: MapSmith **failed** that trap on 2026-08-26
 out, with a manifest recording a successful reprojection — and the pass is the fix, not
 the original behaviour. The run where it failed is still published.
 
-**Six defects have come back from it**, which is the return we wanted from putting the
+**Seven defects have come back from it**, which is the return we wanted from putting the
 suite outside:
 
 - the `datum-ballpark` failure above — 74 m out with a manifest recording a successful
@@ -1167,21 +1182,28 @@ suite outside:
   line was added to 2 km of pipe in silence and every individual row stayed right;
 - two probes answered `unsupported` because nothing could say where a raster's lowest cell
   was;
-- and three probes that came back `unsupported` because MapSmith had no area operation at
+- three probes that came back `unsupported` because MapSmith had no area operation at
   all — `measure_area` exists because a trap said so, and it carries the first check here
-  that asks whether the *number* is right rather than whether the operation ran.
-
-Grid registration was the one MapSmith could not attempt at all when it was published: a
-DEM that declares its values sit at grid nodes rather than filling cells, where every
-position moves half a cell if you ignore the tag. Nothing here read the tag, and no
-operation reported *where* a cell is. Fixed in one module rather than at the point of
-failure, because the defect was in every place that turned an index into a coordinate.
+  that asks whether the *number* is right rather than whether the operation ran;
+- and the seventh, which the suite sent back by being wrong itself. Grid registration was
+  the family MapSmith could not attempt when it was published, and the fix for it was built
+  to the trap's premise: that GDAL leaves a point-registered file's geotransform alone, so
+  the reader must move every position half a cell. GDAL documents the opposite (RFC 33) —
+  it has already moved it — and MapSmith put every sample of such a file half a cell
+  north-west, the Copernicus DEM included, while the trap scored that as a pass. A
+  Copernicus DEM, whose samples fall on whole arc-seconds by its own documentation, found
+  both on 2026-09-25 ([erratum](https://github.com/argleton/argleton/blob/main/results/README.md#erratum-2026-09-25-trap-024)). Positions now come from GDAL's geotransform
+  whatever the tag says, and the terrain engine, which really does misread the tag, gets
+  an area copy instead of a refusal.
 
 ## Notebook gallery
 
-Three executable walkthroughs in [`examples/`](examples/): verified buffer+clip with
+Four executable walkthroughs in [`examples/`](examples/): verified buffer+clip with
 provenance manifests, terrain and hydrology on a real 520×520 USGS DEM of **Mount St.
-Helens**, and a deliberately wrong plan rejected before execution and then repaired. The
+Helens**, a deliberately wrong plan rejected before execution and then repaired, and
+**Copernicus** data on Monte Baldo — a DEM in degrees refused for slope and then reprojected,
+and a Sentinel-2 NDVI whose reflectance offset the catalogue declares and the pixels already
+contain. The
 terrain notebook also shows what happens when reality bites: that DEM is stored with the
 standard TIFF predictor, which Whitebox Workflows 2.x does not undo when reading
 ([upstream report](https://github.com/jblindsay/whitebox_next_gen/issues/32)), so MapSmith
@@ -1254,7 +1276,7 @@ Next, in the order we intend to do it. The linked items carry a written spec —
 - [x] **A suite for the failure every existing benchmark misses** — a result that is wrong and
   reported as successful. It exists, it is not here, and it is not ours to grade:
   [**Argleton**](https://argleton.org) lives in [its own organisation](https://github.com/argleton/argleton)
-  under Apache-2.0. What it measures in MapSmith, including the six defects it has sent back,
+  under Apache-2.0. What it measures in MapSmith, including the seven defects it has sent back,
   has [a section of its own](#what-the-suite-found-in-mapsmith). #25 is closed against Argleton
   rather than left open here.
 - [ ] [Agent-loop repair](https://github.com/mapsmith-ai/MapSmith/issues/26): hand verification failures back to the agent as structured, actionable errors, with a bounded retry budget recorded in the manifest. Our [own measurements](docs/benchmarks.md) say the runtime error message is the information channel that works